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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document specifies the MAC protocol. 
The specification describes: 
MAC architecture; 

- MAC entities; 
channel structure; 

services provided to upper layers; 

- MAC functions; 

services expected from the physical layer; 

elements for layer-to-layer communication including primitives between MAC and RLC; 

elements for peer-to-peer communication; 

protocol data units, formats and parameters; 

elementary procedures. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 25.301: "Radio Interface Protocol Architecture". 

[3] 3GPP TS 25.302: "Services provided by the Physical Layer". 

[4] 3GPP TS 25.303: "Interlayer Procedures in Connected Mode". 

[5] 3GPP TS 25.304: "UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected 

Mode". 

[6] 3GPP TS 25.322: "RLC Protocol Specification". 

[7] 3GPP TS 25.331: "Radio Resource Control (RRC); protocol specification". 

[8] 3GPP TR 25.921: "Guidelines and Principles for Protocol Description and Error Handling". 

[9] 3GPP TR 25.990: "Vocabulary for the UTRAN". 

[10] 3GPP TS 33.102: "Security architecture". 

[II] 3GPP TS 25 .425 : "UTRAN lur Interface User Plane Protocols for Common Transport Channel 
Data Streams". 
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[12] 3GPP TS 25.133: "Requirements for support of radio resource management (FDD)". 

[13] 3GPP TS 25.214: "Physical layer procedures (FDD)". 

[14] 3GPP TS 25.123: "Requirements for support of radio resource management (TDD)". 

[15] 3GPP TS 33.105: "Cryptographic Algorithm Requirements". 

[16] 3GPP TS 25.212: "Multiplexing and Channel Coding (FDD)". 

[17] 3GPP TS 25.215: "Physical layer - Measurements (FDD)". 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given below and in [9] and [1] apply. 

3.1 .1 HS-DSCH Specific Definitions 

3.1 .2 E-DCH Specific Definitions 

Active Process: HARQ process for which Scheduling Grant are applicable, i.e. scheduled data can be sent. 

AG_Timer: This timer is set to one HARQ RTT (40ms in the case of 10ms TTl, 16ms in the case of 2ms TTI). 

E-DCH: The Enhanced Dedicated Channel (E-DCH) is an uplink transport channel. 

E-DCH active set: The set of cells which carry the E-DCH for one UE. 

HARQ profile: One HARQ profile consists of a power offset attribute and maximum number of transmissions. 

Inactive Process: HARQ process for which Scheduling Grants are not applicable, i.e. scheduled data cannot be sent. 

INACTIVE: Absolute Grant value that can be sent by the serving cell's scheduler on the E-AGCH to deactivate a 
process or to switch the UE to its secondary E-RNTl. 

Maximuin_Serving_Grant: The variable Maximum_Serving_Grant indicates the maximum E-DPDCH to DPCCH 
power ratio that the UE is allowed to use for scheduled data while the timer Non_Serving_RG_Timer has not expired. 

Maximum number of re-transmissions, Maximum number of transmissions: Maximum number of re-transmissions 
= maximum number of transmissions - 1. Both these notations are used. 

Minimum_Grant: The value Minimum_Grant corresponds to the minimum E-DPDCH to DPCCH power ratio that the 
UE considers. This value is (5/15)^^2. 

Non-serving E-DCH RL or Non-serving RL: Cell which belongs to the E-DCH active set but does not belong to the 
Serving E-DCH RLS and from which the UE can receive one Relative Grant. The UE can have zero, one or several 
Non-serving E-DCH RL(s). 

Non_Serving_RG_Timer: This timer is set to one HARQ RTT (40ms in the case of 10ms TTl, 16ms in the case of 
2ms TTI). 

Power offset attribute: Represents the power offset between E-DPDCH(s) and reference E-DPDCH power level for a 
given E-TFC. This power offset attribute is set to achieve the required QoS in this MAC-d flow when carried alone in a 
MAC-e PDU and subsequently in the corresponding CCTrCh of E-DCH type. Details on the mapping on Beta factors 
can be found in [13]. The reference E-DPDCH power offset is signaled to the UE for one (or several) reference E- 
TFC(s) (see details in subclause 11.1). 

Primary Absolute Grant: Absolute Grant received with the primary E-RNTI. 
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Primary_Grant_Available: This state variable is a Boolean, indicating whether the UE"s serving grant is only affected 
by Primary Absolute Grants and Relative Grants (i.e. not by Secondary Absolute Grants). 

reference_ETPR: The state variable reference_ETPR holds the E-DPDCH to DPCCH power ratio used as reference 
for relative grant commands. This variable is set to the E-DPDCH to DPCCH power ratio used for the E-TFC selected 
for the previous TTI on this HARQ process, calculated using the amplitude ratios prior to the quantization according to 
subclause 5.1.2.5B.2.3 of [13], excluding non-scheduled transmissions, excluding any scaling applied according to 
subclause 5.1.2.6 of [13] and is obtained from the physical layer. In case no scheduled transmission took place on a 
HARQ process in the previous TTI, reference_ETPR shall be set to Minimum_Grant for this HARQ process. 

Secondary Absolute Grant: Absolute Grant received with the secondary E-RNTI. 

Serving E-DCH cell: Cell from which the UE receives Absolute Grants from the Node-B scheduler. A UE has one 
Serving E-DCH cell. 

Serving E-DCH RLS or Serving RLS: Set of cells which contains at least the Serving E-DCH cell and from which the 
UE can receive and combine one Relative Grant. The UE has only one Serving E-DCH RLS. 

Serving_Grant: The state variable Serving_Grant indicates the maximum E-DPDCH to DPCCH power ratio that the 
UE is allowed to use for scheduled data in the following transmission. The value in the appropriate state variable will be 
provided to the E-TFC selection function to help in selecting the best format for the upcoming transmission. Possible 
values are: "Zero_Grant" and numerical values. 

Stored_Secondary_Grant: This state variable is used to store the last received Secondary Absolute Grant Value. 
Possible values are: "Zero Grant" and numerical values. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AG Absolute Grant 

ASC Access Service Class 

BCCH Broadcast Control Channel 

BCH Broadcast Channel 

C- Control- 

CCCH Common Control Channel 

DCCH Dedicated Control Channel 

DCH Dedicated Channel 

DL Downlink 

DSCH Downlink Shared Channel 

DTCH Dedicated Traffic Channel 

E-AGCH E-DCH Absolute Grant Channel 

E-DCH Enhanced Dedicated Transport Channel 

E-DPCCH E-DCH Dedicated Physical Control Channel 

E-HICH E-DCH HARQ Acknowledgement Indicator Channel 

E-RGCH E-DCH Relative Grant Channel 

E-RNTI E-DCH Radio Network Temporary Identifier 

E-TFC E-DCH Transport Format Combination 

E-TFCI E-DCH Transport Format Combination Indicator 

EACH Forward Link Access Channel 

FDD Frequency Division Duplex 

HARQ Hybrid Automatic Repeat Request 

HCSN HS-SCCH CycHc Sequence Number 

HSDPA High Speed Downlink Packet Access 

HS-DSCH High Speed Downlink Shared Channel 

LI Layer 1 (physical layer) 

L2 Layer 2 (data link layer) 

L3 Layer 3 (network layer) 

MAC Medium Access Control 

MBMS Multimedia Broadcast Multicast Service 

MCCH MBMS point-to-multipoint Control Channel 

MTCH MBMS point-to-multipoint Traffic Channel 
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MSCH MBMS point-to-multipoint Scheduling Channel 

PCCH Paging Control Channel 

PCH Paging Channel 

PDU Protocol Data Unit 

PHY Physical layer 

PhyCH Physical Channels 

RACH Random Access Channel 

RG Relative Grant 

RLC Radio Link Control 

RLS Radio Link Set 

RNC Radio Network Controller 

RNS Radio Network Subsystem 

RNTI Radio Network Temporary Identity 

RRC Radio Resource Control 

RSN Retransmission Sequence Number 

SAP Service Access Point 

SDU Service Data Unit 

SHCCH Shared Channel Control Channel 

SRNC Serving Radio Network Controller 

SRNS Serving Radio Network Subsystem 

TDD Time Division Duplex 

TFCI Transport Format Combination Indicator 

TFI Transport Format Indicator 

TSN Transmission Sequence Number 

U- User- 

UE User Equipment 

UL Uphnk 

UMTS Universal Mobile Telecommunications System 

USCH Uplink Shared Channel 

UTRA UMTS Terrestrial Radio Access 

UTRAN UMTS Terrestrial Radio Access Network 



4 General 

4.1 Objective 

The objective is to describe the MAC architecture and the different MAC entities from a functional point of view. 



4.2 



MAC architecture 



The description in this subclause is a model and does not specify or restrict implementations. 

According to the RRC functions the RRC is generally in control of the internal configuration of the MAC. 



4.2.1 



IVIAC Entities 



The diagrams that describe the MAC architecture are constructed from MAC entities. 
The entities are assigned the following names. 

MAC-b is the MAC entity that handles the following transport channels: 

broadcast channel (BCH) 
MAC-c/sh/m, is the MAC entity that handles the following transport channels: 
paging channel (PCH) 
forward access channel (EACH) 
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random access channel (RACH) 

downlink shared channel (DSCH). The DSCH exists only in TDD mode. 

uplink shared channel (USCH). The USCH exists only in TDD mode. 
MAC-d is the MAC entity that handles the following transport channels: 

dedicated transport channel (DCH) 
MAC-hs is the MAC entity that handles the following transport channels: 

high speed downlink shared channel (HS-DSCH) 
MAC-m is the MAC entity that handles the following transport channels: 

forward access channel (FACH). 
MAC-e/es are the MAC entities that handle the following transport channels: 

enhanced dedicated transport channel (E-DCH). 

The exact functions completed by the entities are different in the UE from those completed in the UTRAN. 

NOTE: When a UE is allocated resources for exclusive use by the bearers that it supports the MAC-d entities 

dynamically share the resources between the bearers and are responsible for selecting the TFI/ TFCI that 
is to be used in each transmission time interval. 

4.2.2 MAC-b 

The following diagram illustrates the connectivity of the MAC-b entity in a UE and in each cell of the UTRAN. 

MAC-b represents the control entity for the broadcast channel (BCH). 

There is one (current cell) or multiple (current and neighbour cells) MAC-b entities in each UE and one MAC-b in the 
UTRAN for each cell. 

The MAC Control SAP is used to transfer Control information to MAC-b. 

The MAC-b entity is located in the Node B. 

BCCH Mac Control 




BCH 



Figure 4.2.2.1 : UE side and UTRAN side archiitecture 



4.2.3 Traffic Related Architecture - UE Side 

Figure 4.2.3.1 illustrates the connectivity of MAC entities. 
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The MAC-c/sh/m controls access to all common transport channels, except the HS-DSCH transport channel. 

The MAC-d controls access to all dedicated transport channels, to MAC-c/sh/m and MAC-hs. 

The MAC-hs controls access to the HS-DSCH transport channel. 

The MAC-e/es controls access to the E-DCH transport channel. 

In case of selective combining of MTCH channels from multiple cells, the MAC-m controls access to the FACH 
transport channels used to carry MTCH and MSCH. 

In the downlink, if logical channels of dedicated type are mapped to common transport channels then MAC-d receives 
the data from MAC-c/sh/m or MAC-hs via the illustrated connection between the functional entities. 

In the uplink, if logical channels of dedicated type are mapped to common transport channels then MAC-d submits the 
data to MAC-c/sh/m via the illustrated connection between the functional entities. 

The mapping of logical channels on transport channels depends on the multiplexing that is configured by RRC. 

The MAC Control SAP is used to transfer Control information to each MAC entity. 

The associated signalling shown in the figure illustrates the exchange of information between layer 1 and layer 2 
provided by primitives shown in [3]. 



MTCHMSCH MTCHMSCH MCCH 



MAC-es / 
MAC-e 



MAC-m 



E-DCH ! 



Associated Associated 

Downlinl: Uplink 

Signalling Signalling 



^ 



PCCH BCCH CCCH CTCH SHCCH ControlDCCH DTQH , DTCH 



<i-4^-<i^^ 



MAC-hs 



MAC-c/sh/m 



■ HS-DSCH I PCH FACH 

Associated Associated FACH RACH 




Downlink 

Signalling 



Uplink 
Signalline 



USCH DSCH 

( TDD only ) (TDD only 

USCH DSCH 

( TDD only ) (TDD only ) 



Figure 4.2.3.1 : UE side IVIAC archiitecture 

4.2.3.1 MAC-c/sh/m entity - UE Side 

Figure 4.2.3.1.1 shows the UE side MAC-c/sh/m entity. 
The following functionality is covered: 

- TCTF MUX: 

this function represents the handling (insertion for uplink channels and detection and deletion for downlink 

channels) of the TCTF field in the MAC header, and the respective mapping between logical and transport 

channels. 

The TCTF field indicates the common logical channel type, or if a dedicated logical channel is used; 

- add/read UE Id: 

the UE Id is added for RACH transmissions; 
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the UE Id, when present, identifies data to this UE. 
- read MBMS Id: 

- the MBMS Id is read in case of MTCH reception; 

- the MBMS Id identifies received data to an MBMS service. 
UL: TF selection: 

in the uplink, the possibility of transport format selection exists. 

ASC selection: 

For RACH, MAC indicates the ASC associated with the PDU to the physical layer. This is to ensure that 
RACH messages associated with a given Access Service Class (ASC) are sent on the appropriate signature(s) 
and time slot(s). MAC also applies the appropriate back-off parameter(s) associated with the given ASC. 
When sending an RRC CONNECTION REQUEST message, RRC will determine the ASC; in all other cases 
MAC selects the ASC; 

scheduling /priority handling 

this functionality is used to transmit the information received from MAC-d on RACH based on logical 
channel priorities. This function is related to TF selection. 

TFC selection 

transport format and transport format combination selection according to the transport format combination 
set (or transport format combination subset) configured by RRC is performed. 

The RLC provides RLC-PDUs to the MAC, which fit into the available transport blocks on the transport channels. 

There is one MAC-c/sh/m entity in each UE. 



£75/ 



3GPP TS 25.321 version 6.10.0 Release 6 



14 



ETSI TS 125 321 V6.10.0 (2006-09) 



POCISHCCH (TDD only) CCCH CTCH BCCH MCCH MSCH MTCH MTCH 



MAC - Control 




DSCH DSCH 

TDD only TDD only 



USCH USCH 

TDD only TDD only 



FACH FACH 



Figure 4.2.3.1.1 : UE side IVIAC architecture / IVIAC-c/sh/m details 

4.2.3.1b MAC-m entity -UE Side 

Figure 4.2.3. lb. 1 shows the UE side MAC-m entity. 
The following functionality is covered: 

- TCTF DEMUX: 

this function represents the handling (detection and deletion for downlink channels) of the TCTF field in the 
MAC header, and the respective mapping between logical and transport channels. 
The TCTF field indicates the common logical channel type; 

- read MBMS Id 

- the MBMS Id is read in case of MTCH reception; 

- the MBMS Id identifies received data to an MBMS service. 

The MAC Control SAP is used to transfer control information to MAC-m. 

If MTCH channels are selectively combined, the MAC-m entity exists in the UE. Otherwise, the MAC-m entity does 
not exist. 

In case of selective combining of MTCH channels from multiple cells, there are one MAC-c/sh/m for the current cell 
and one MAC-m entity for each neighboring cell in the UE. 
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Figure 4.2.3.1 b.1 : UE side lUIAC architecture / lUIAC-m details 
4.2.3.2 MAC-d entity - UE Side 

Figure 4.2.3.2.1 shows the UE side MAC-d entity. 

The following functionality is covered: 

Transport Channel type switching 

Transport Channel type switching is performed by this entity, based on decision taken by RRC. This is 
related to a change of radio resources. If requested by RRC, MAC shall switch the mapping of one 
designated logical channel between common and dedicated transport channels. 

- C/T MUX: 

The C/T MUX is used when multiplexing of several dedicated logical channels onto one transport channel 
(other than HS-DSCH) or one MAC-d flow (HS-DSCH) is used. An unambiguous identification of the 
logical channel is included. 

Ciphering: 

Ciphering for transparent mode data to be ciphered is performed in MAC-d. Details about ciphering can be 
found in [10]. 

Deciphering: 

Deciphering for ciphered transparent mode data is performed in MAC-d. Details about ciphering can be 
found in [10]. 

UL TFC selection: 

- Transport format and transport format combination selection according to the transport format combination 
set (or transport format combination subset) configured by RRC is performed. 

The MAC-d entity is responsible for mapping dedicated logical channels for the uplink either onto dedicated transport 
channels or to transfer data to MAC-c/sh/m to be transmitted via common channels. 

One dedicated logical channel can be mapped simultaneously onto DCH and DSCH in TDD mode. 

One dedicated logical channel can be simultaneously mapped onto DCH and HS-DSCH. 

The MAC-d entity has a connection to the MAC-c/sh/m entity. This connection is used to transfer data to the MAC- 
c/sh/m to transmit data on transport channels that are handled by MAC-c/sh/m (uplink) or to receive data from transport 
channels that are handled by MAC-c/sh/m (downlink). 
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The MAC-d entity has a connection to the MAC-hs entity. This connection is used to receive data from the HS-DSCH 
transport channel which is handled by MAC-hs (downlink). 

The MAC-d entity has a connection to the MAC-e/es entity. This connection is used to transmit data on the E-DCH 
transport channel which is handled by the MAC-e/es (uplink). 

There is one MAC-d entity in the UE. 
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Figure 4.2.3.2.1 : UE side IVIAC arcliitecture / IVIAC-d details 



4.2.3.3 MAC-hs entity - UE Side 

The MAC-hs handles the HSDPA specific functions. In the model below the MAC-hs comprises the following entities: 

- HARQ: 

The HARQ entity is responsible for handling the MAC functions relating to the HARQ protocol. The HARQ 
functional entity handles all the tasks that are required for hybrid ARQ. It is responsible for generating ACKs or 
NACKs. The detailed configuration of the hybrid ARQ protocol is provided by RRC over the MAC-Control 
SAP. 

Reordering Queue distribution: 

The reordering queue distribution function routes the MAC-hs PDUs to the correct reordering buffer based on 

the Queue ID. 

Reordering: 

The reordering entity reorders received MAC-hs PDUs according to the received TSN. MAC-hs PDUs with 
consecutive TSNs are delivered to the disassembly function upon reception. MAC-hs PDUs are not delivered to 
the disassembly function if MAC-hs PDUs with lower TSN are missing. There is one reordering entity for each 
Queue ID configured at the UE. 

Disassembly: 

The disassembly entity is responsible for the disassembly of MAC-hs PDUs. When a MAC-hs PDU is 
disassembled the MAC-hs header is removed, the MAC-d PDUs are extracted and any present padding bits are 
removed. Then the MAC-d PDUs are delivered to higher layer. 

The associated signalling shown in the figure illustrates the exchange of information between layer 1 and layer 2 
provided by primitives shown in [3]. 
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Figure 4.2.3.3.1 : UE side IVIAC archiitecture / IVJAC-his details 



MAC-e/es entity - UE Side 



The MAC-es/e handles the E-DCH specific functions. The spUt between MAC-e and MAC-es in the UE is not detailed. 
In the model below the MAC-e/es comprises the following entities: 

- HARQ: 

The HARQ entity is responsible for handling the MAC functions relating to the HARQ protocol. It is responsible 
for storing MAC-e payloads and re-transmitting them. The detailed configuration of the hybrid ARQ protocol is 
provided by RRC over the MAC-Control SAP. The HARQ entity provides the E-TFC, the retransmission 
sequence number (RSN), and the power offset to be used by LI . Redundancy version (RV) of the HARQ 
transmission is derived by LI from RSN, CFN and in case of 2 ms TTI from the sub-frame number. 

Multiplexing and TSN setting: 

The multiplexing and TSN setting entity is responsible for concatenating multiple MAC-d PDUs into MAC-es 
PDUs, and to multiplex one or multiple MAC-es PDUs into a single MAC-e PDU, to be transmitted in the next 
TTI, as instructed by the E-TFC selection function. It is also responsible for managing and setting the TSN per 
logical channel for each MAC-es PDU. 

E-TFC selection: 

This entity is responsible for E-TFC selection according to the scheduling information (Relative Grants and 
Absolute Grants) received from UTRAN via LI and Serving Grant value signalled through RRC, and for 
arbitration among the different flows mapped on the E-DCH. The detailed configuration of the E-TFC entity is 
provided by RRC over the MAC-Control SAP. The E-TFC selection function controls the multiplexing function. 
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Figure 4.2.3.4.1 : UE side lUIAC architecture / lUIAC-e/es details 

4.2.4 Traffic Related Architecture - UTRAN Side 

Figure 4.2.4.1 illustrates the connectivity between the MAC entities from the UTRAN side. 

It is similar to the UE case with the exception that there will be one MAC-d for each UE and each UE (MAC-d) that is 
associated with a particular cell may be associated with that cell's MAC-c/sh/m. 

MAC-c/sh/m is located in the controlling RNC while MAC-d is located in the serving RNC. MAC-hs is located in the 
Node B. The MAC-d PDUs to be transmitted are transferred from MAC-c/sh/m to the MAC-hs via the lub interface in 
case of configuration with MAC-c/sh/m, or from the MAC-d via lur/lub in case of configuration without MAC-c/sh/m. 

For each UE that uses E-DCH, one MAC-e entity per Node-B and one MAC-es entity in the SRNC are configured. 
MAC-e, located in the Node B, controls access to the E-DCH and is connected to MAC-es, located in the SRNC. MAC- 
es is further connected to MAC-d. There is one transport bearer set up per E-DCH MAC-d flow. 

The MAC Control SAP is used to transfer Control information to each MAC entity belonging to one UE. 

The associated signalling shown in the figure illustrates the exchange of information between layer 1 and layer 2 
provided by primitives shown in [3]. 
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Figure 4.2.4.1 : UTRAN side IVIAC architecture 

4.2.4.1 MAC-c/sh/m entity - UTRAN Side 

Figure 4.2.4.1.1 shows the UTRAN side MAC-c/sh/m entity. The following functionality is covered: 

Scheduling - Buffering - Priority Handling; 

this function manages FACH and for TDD DSCH resources between the UEs and between data flows 
according to their priority and delay requirements set by higher layers. 

- TCTF MUX 

this function represents the handling (insertion for downlink channels and detection and deletion for uplink 

channels) of the TCTF field in the MAC header, and the respective mapping between logical and transport 

channels. 

The TCTF field indicates the common logical channel type, or if a dedicated logical channel is used; 

- UE Id Mux; 

for dedicated type logical channels, the UE Id field in the MAC header is used to distinguish between UEs; 

- MBMS Id Mux; 

for MTCH channels, the MBMS Id field in the MAC header is used to distinguish between MBMS services; 
TFC selection: 

in the downlink, transport format combination selection is done for FACH and PCH and for TDD DSCHs; 

Demultiplex; 

for TDD operation the demultiplex function is used to separate USCH data from different UEs, i.e. to be 
transferred to different MAC-d entities; 

- DL code allocation; 

for TDD this function is used to indicate the code used on the DSCH; 
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Flow control; 

a flow control function exists toward MAC-d to limit buffering between MAC-d and MAC-c/sh/m entities, a 
flow control function also exists towards MAC-hs in case of configuration with MAC-c/sh/m. 

The RLC provides RLC-PDUs to the MAC, which fit into the available transport blocks on the transport channels. 

There is one MAC-c/sh/m entity in the UTRAN for each cell; 
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Figure 4.2.4.1.1 : UTRAN side IVIAC architecture / lUIAC-c/sh/m details 
4.2.4.2 MAC-d entity - UTRAN Side 

Figure 4.2.4.2.1 shows the UTRAN side MAC-d entity. 
The following functionality is covered: 

- Transport Channel type switching: 

Transport Channel type switching is performed by this entity, based on decision taken by RRC; this is related 
to a change of radio resources. If requested by RRC, MAC shall switch the mapping of one designated 
logical channel between common and dedicated transport channels. 

- C/T MUX box; 

the function includes the C/T field when multiplexing of several dedicated logical channels onto one 
transport channel (other than HS-DSCH) or one MAC-d flow (HS-DSCH) is used. 

Priority setting; 

- This function is responsible for priority setting on data received from DCCH / DTCH; 

Ciphering; 

Ciphering for transparent mode data to be ciphered is performed in MAC-d. Details about ciphering can be 
found in [10]. 
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Deciphering; 

Deciphering for ciphered transparent mode data is performed in MAC-d. Details about ciphering can be 
found in [10]. 

DL Scheduling/Priority handling; 

in the downlink, scheduling and priority handling of transport channels is performed within the allowed 
transport format combinations of the TFCS assigned by the RRC. 

Flow Control; 

a flow control function exists toward MAC-c/sh/m to limit buffering between MAC-d and MAC-c/sh/m 
entities. This function is intended to limit layer 2 signalling latency and reduce discarded and retransmitted 
data as a result of EACH or for TDD DSCH congestion. For the lur interface this is specified in [11]. A flow 
control function also exists towards MAC-hs in case of configuration without MAC-c/sh/m, see subclause 
4.2.4.2. 

A MAC-d entity using common channels other than the high speed downlink shared channel is connected to a MAC- 
c/sh/m entity that handles the scheduling of the common channels to which the UE is assigned and DL (FACH) priority 
identification to MAC-c/sh/m; 

A MAC-d entity using downlink shared channel is connected to a MAC-c/sh/m entity that handles the shared channels 
to which the UE is assigned and indicates the level of priority of each PDU to MAC-c/sh/m; 

A MAC-d entity using the high speed downlink shared channel may be connected to a MAC-c/sh/m entity that in turn is 
connected to the MAC-hs entity in the Node B (configuration with MAC-c/sh/m); alternately, a MAC-d entity using the 
high speed downlink shared channel may be connected to the MAC-hs entity in the Node B in case of configuration 
without MAC-c/sh/m. 

A MAC-d entity using the enhanced dedicated transport channel (Uplink only) is connected to a MAC-es entity that 
handles the re-ordering and combining of data received from different Node Bs. Given that the MAC-es is collocated in 
the SRNC, it is not necessary to flow control this connection. The MAC-es indicates the logical channel for which the 
data is intended, to allow the MAC-d to route it appropriately. 

A MAC-d entity is responsible for mapping dedicated logical channels onto the available dedicated transport channels 
or routing the data received on a DCCH or DTCH to MAC-c/sh/m or to MAC-hs. 

One dedicated logical channel can be mapped simultaneously on DCH and DSCH in TDD mode. Different scheduling 
mechanisms apply for DCH and DSCH. One dedicated logical channel can be mapped simultaneously on DCH and HS- 
DSCH. 

There is one MAC-d entity in the UTRAN for each UE that has one or more dedicated logical channels to or from the 
UTRAN. 
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Figure 4.2.4.2.1 : UTRAN side IVIAC architecture / IVIAC-d details 



MAC-hs entity - UTRAN Side 



There is one MAC-hs entity in the UTRAN for each cell that supports HS-DSCH transmission. The MAC-hs is 
responsible for handling the data transmitted on the HS-DSCH. Furthermore it is responsible for the management of the 
physical resources allocated to HSDPA. MAC-hs receives configuration parameters from the RRC layer via the MAC- 
Control SAP. There should be priority handling per MAC-d PDU in the MAC-hs. The MAC-hs is comprised of four 
different functional entities: 

Flow Control: 

This is the companion flow control function to the flow control function in the MAC-c/sh/m in case of 
configuration with MAC-c/sh/m and MAC-d in case of configuration without MAC-c/sh/m. Both entities 
together provide a controlled data flow between the MAC-c/sh/m and the MAC-hs (Configuration with MAC- 
c/sh/m) or the MAC-d and MAC-hs (Configuration without MAC-c/sh/m) taking the transmission capabilities of 
the air interface into account in a dynamic manner. This function is intended to limit layer 2 signalling latency 
and reduce discarded and retransmitted data as a result of HS-DSCH congestion. Flow control is provided 
independently by MAC-d flow for a given MAC-hs entity. 

Scheduling/Priority Handling: 

This function manages HS-DSCH resources between HARQ entities and data flows according to their priority. 
Based on status reports from associated uplink signalling either new transmission or retransmission is 
determined. Further it determines the Queue ID and TSN for each new MAC-hs PDU being serviced, and in the 
case of TDD the HCSN is determined. A new transmission can be initiated instead of a pending retransmission at 
any time to support the priority handling. 

- HARQ: 

One HARQ entity handles the hybrid ARQ functionality for one user. One HARQ entity is capable of supporting 
multiple instances (HARQ process) of stop and wait HARQ protocols. There shall be one HARQ process per 
HS-DSCH per TTI. 

TFRC selection: 

Selection of an appropriate transport format and resource for the data to be transmitted on HS-DSCH. 
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The associated signalling shown in the figure illustrates the exchange of information between layer 1 and layer 2 
provided by primitives shown in [3]. 
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Figure 4.2.4.3.1 : UTRAN side lUIAC architecture / lUIAC-hs details 



MAC-es entity - UTRAN Side 



For each UE, there is one MAC-es entity in the SRNC. The MAC-es sublayer handles E-DCH specific functionality, 
which is not covered in the MAC-e entity in Node B. In the model below, the MAC-es comprises the following entities: 

Reordering Queue Distribution: 

The reordering queue distribution function routes the MAC-es PDUs to the correct reordering buffer based on 

the SRNC configuration. 

Reordering: 

This function reorders received MAC-es PDUs according to the received TSN and Node-B tagging i.e. (CFN, 
subframe number). MAC-es PDUs with consecutive TSNs are delivered to the disassembly function upon 
reception. Mechanisms for reordering MAC-es PDUs received out-of-order are left up to the implementation. 
There is one Re-ordering Process per logical channel. 

Macro diversity selection: 

The function is performed in the MAC-es, in case of soft handover with multiple Node-Bs (The soft combining 
for all the cells of a Node-B takes place in the Node-B). This means that the reordering function receives 
MAC-es PDUs from each Node-B in the E-DCH active set. The exact implementation is not specified. 
However the model below is based on one Reordering Queue Distribution entity receiving all the MAC-d flow 
from all the Node-Bs, and one MAC-es entity per UE. 

Disassembly: 

The disassembly function is responsible for disassembly of MAC-es PDUs. When a MAC-es PDU is 

disassembled the MAC-es header is removed, the MAC-d PDU"s are extracted and delivered to MAC-d. 
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Figure 4.2.4.4-1 : UTRAN side IVIAC architecture / IVIAC-es details (SHO case) 



MAC-e entity - UTRAN Side 



There is one MAC-e entity in the Node B for each UE and one E-DCH scheduler function in the Node-B. The MAC-e 
and E-DCH scheduler handle HSUPA specific functions in the Node B. In the model below, the MAC-e and E-DCH 
scheduler comprises the following entities: 

- E-DCH Scheduling: 

This function manages E-DCH cell resources between UEs. Based on scheduling requests, Scheduling Grants 
are determined and transmitted. The general principles of the E-DCH scheduling are described in subclause 
1 1.8.2.3 below. However implementation is not specified (i.e. depends on RRM strategy). 

- E-DCH Control: 

The E-DCH control entity is responsible for reception of scheduling requests and transmission of Scheduling 
Grants. The general principles of the E-DCH schedulling are described in subclause 11.8.2.3 below. 

De-multiplexing: 

This function provides de-multiplexing of MAC-e PDUs. MAC-es PDUs are forwarded to the associated 

MAC-d flow. 

- HARQ: 

One HARQ entity is capable of supporting multiple instances (HARQ processes) of stop and wait HARQ 
protocols. Each process is responsible for generating ACKs or NACKs indicating delivery status of E-DCH 
transmissions. The HARQ entity handles all tasks that are required for the HARQ protocol. 

The associated signalling shown in the figure illustrates the exchange of information between layer 1 and layer 2 
provided by primitives. 
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Figure 4.2.4.5-1 : UTRAN side IVIAC architecture / IVIAC-e details 

4.3 Channel structure 

The MAC operates on the channels defined below; the transport channels are described between MAC and Layer 1 , the 
logical channels are described between MAC and RLC. 

The following subclauses provide an overview, the normative description can be found in [2] and [3] respectively. 

4.3.1 Transport channels 

Common transport channel types are: 

- Random Access Channel(s) (RACH); 

- Forward Access Channel(s) (FACH); 

- Downlink Shared Channel(s) (DSCH), for TDD operation only; 

- High Speed Downlink Shared Channel(s) (HS-DSCH); 
Uplink Shared Channel(s) (USCH), for TDD operation only; 

- Broadcast Channel (BCH); 

- Paging Channel (PCH). 
Dedicated transport channel types are: 

- Dedicated Channel (DCH); 

- Enhanced Dedicated Channel (E-DCH) for UL FDD operation only. 

4.3.2 Logical Channels 

The MAC layer provides data transfer services on logical channels. A set of logical channel types is defined for 
different kinds of data transfer services as offered by MAC. 

Each logical channel type is defined by what type of information is transferred. 
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4.3.2.1 Logical channel structure 

The configuration of logical channel types is depicted in figure 4.3.2.1. 
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Figure 4.3.2.1 : Logical channel structure 

4.3.2.2 Control Channels 

Following control channels are used for transfer of control plane information only: 

- Broadcast Control Channel (BCCH); 

- Paging Control Channel (PCCH); 

- Common Control Channel (CCCH); 

- Dedicated Control Channel (DCCH); 

- Shared Channel Control Channel (SHCCH); 

- MEMS point-to-multipoint Control Channel (MCCH); 

- MEMS point-to-multipoint Scheduhng Channel (MSCH) 

4.3.2.3 Traffic Channels 

Following traffic channels are used for the transfer of user plane information only: 

- Dedicated Traffic Channel (DTCH); 
Common Traffic Channel (CTCH); 

- MEMS point-to-multipoint Traffic Channel (MTCH). 

5 Services provided to upper layers 

This clause describes the different services provided by the MAC to higher layers. For a detailed description of the 
following functions see [2]. 
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5.1 Description of Services provided to upper layers 

Data transfer: This service provides unacknowledged transfer of MAC SDUs between peer MAC entities 
without data segmentation. 

Reallocation of radio resources and MAC parameters: This service performs on request of RRC execution of 
radio resource reallocation and change of MAC parameters. 

Reporting of measurements: Local measurements are reported to RRC. 



6 Functions 

6.1 Description of the IVIAC functions 

The functions of MAC include: 

mapping between logical channels and transport channels; 

selection of appropriate Transport Format for each Transport Channel depending on instantaneous source rate; 

priority handling between data flows of one UE; 

priority handling between UEs by means of dynamic scheduling; 

identification of UEs on common transport channels; 

identification of MBMS services on common transport channels; 

multiplexing/demultiplexing of upper layer PDUs into/from transport blocks delivered to/from the physical layer 
on common transport channels; 

multiplexing/demultiplexing of upper layer PDUs into/from transport block sets delivered to/from the physical 
layer on dedicated transport channels; 

traffic volume measurement; 

Transport Channel type switching; 

ciphering for transparent mode RLC; 

Access Service Class selection for RACH transmission; 

control of HS-DSCH transmission and reception including support of HARQ; 

HS-DSCH Provided Bit Rate measurement; 

control of E-DCH transmission and reception including support of HARQ; 

generation of uplink scheduling information to assist with E-DCH resource allocation; 

E-DCH Provided Bit-rate measurement. 



£75/ 



3GPP TS 25.321 version 6.10.0 Release 6 



28 



ETSI TS 125 321 V6.10.0 (2006-09) 



6.2 Relation between MAC Functions and Transport Channels 

6.2.1 Relation between IVIAC Functions and Transport Channels in 
UTRAN 

Table 6.2.1.1 : UTRAN MAC functions corresponding to the transport channel 



Associated 

MAC 
Functions 


Logical 
Ch 


Trans 
port 
Ch 


TF 

Sele 

ctio 

n 


Priority 

handling 

between 

UEs 


Priority 
handling 
(one UE) 


Sche 
dulin 

g 


Identific 

ation of 

UEsor 

MBMS 

services 


Mux/ 
Demux 

on 
common 
transport 
channels 


Mux/ 
Demux on 
dedicated 
transport 
channels 


HARQ 

supp 

ort 


Uplink 
(Rx) 


CCCH 


RACH 












X 






DCCH 


RACH 










X 


X 






DCCH 


DCH 














X 




DTCH 


RACH 










X 


X 






DTCH 


DCH 














X 




SHCCH 


RACH 










X 


X 






SHCCH 


USCH 












X 






DTCH 


USCH 












X 






DCCH 


USCH 












X 






DTCH 


E- 
DCH 








X 






X 


X 


DCCH 


E- 
DCH 








X 






X 


X 


Downlink 
(Tx) 


BCCH 


BCH 








X 










BCCH 


FACH 


X 






X 




X 






PCCH 


PCH 


X 






X 










CCCH 


FACH 


X 


X 




X 




X 






CTCH 


FACH 


X 






X 




X 






MCCH 


FACH 


X 






X 




X 






MSCH 


FACH 


X 






X 




X 






MTCH 


FACH 


X 






X 


X 


X 






CTCH 


FACH 


X 






X 




X 






DCCH 


FACH 


X 


X 




X 


X 


X 






DCCH 


DSCH 


X 


X 






X 


X 






DCCH 


DCH 


X 




X 








X 




DCCH 


HS- 
DSCH 


X 

(1) 


X 


X 


X 


X 


X 




X 


DTCH 


FACH 


X 


X 




X 


X 


X 






DTCH 


DSCH 


X 


X 






X 


X 






DTCH 


DCH 


X 




X 








X 




DTCH 


HS- 
DSCH 


X 

(1) 


X 


X 


X 


X 


X 




X 


SHCCH 


FACH 


X 


X 




X 




X 






SHCCH 


DSCH 


X 


X 








X 







NOTE 1 : In case of HS-DSCH the TF selection is replaced by TFRC selection. 
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6.2.2 Relation of MAC Functions ar\6 Transport CInannels in UE 

Table 6.2.2.1 : UE MAC functions corresponding to the transport channel 



Associated 

IVIAC 
Functions 


Logical 
Ch 


Transp 
ortCh 


TF 
Selection 


Priority 
handling 
(one UE) 


Identification 


Mux/Demux 

on common 

transport 

channels 


Mux/Demux 

on dedicated 

transport 

channels 


HARQ 

suppor 

t 


Uplink 
(Tx) 


CCCH 


RACH 








X 






DCCH 


RACH 


X 


X 


X 


X 






DCCH 


DCH 


X 


X 






X 




DTCH 


RACH 


X 


X 


X 


X 






DTCH 


DCH 


X 


X 






X 




SHCCH 


RACH 








X 






SHCCH 


USCH 


X 


X 




X 






DCCH 


USCH 


X 


X 




X 






DTCH 


USCH 


X 


X 




X 






DCCH 


E-DCH 


X 


X 






X 


X 


DTCH 


E-DCH 


X 


X 






X 


X 


Downlink 
(Rx) 


BCCH 


BCH 














BCCH 


FACH 








X 






PCCH 


PCH 














CCCH 


FACH 








X 






CTCH 


FACH 








X 






MCCH 


FACH 








X 






MSCH 


FACH 








X 






MTCH 


FACH 






X 


X 






DCCH 


FACH 






X 


X 






DCCH 


DSCH 








X 






DCCH 


DCH 










X 




DCCH 


HS- 
DSCH 






X 


X 




X 


DTCH 


FACH 






X 


X 






DTCH 


DSCH 








X 






DTCH 


DCH 










X 




DTCH 


HS- 
DSCH 






X 


X 




X 


SHCCH 


FACH 








X 






SHCCH 


DSCH 








X 







7 



Services expected from physical layer 



The physical layer offers information transfer services to MAC. For detailed description, see [3]. 



8 



Elements for layer-to-layer communication 



The interaction between the MAC layer and other layers are described in terms of primitives where the primitives 
represent the logical exchange of information and control between the MAC layer and other layers. The primitives shall 
not specify or constrain implementations. The MAC is connected to layer 1, RLC and RRC. The following subclauses 
describe the primitives between these layers. 
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8.1 Primitives between layers 1 and 2 

8.1.1 Primitives 

The primitives are described in [3]. 

8.1.2 Parameters 

a) Transport Format Resource Indicator (TFRI) for HS-DSCH: 

For HS-DSCH the Transport Block size is derived from the TFRI value signalled on the HS-SCCH. The 
mapping between TFRI value and Transport Block size is specified in subclause 9.2.3. 

b) HARQ information for E-DCH: 

ACK/NACK information (details specified in subclause 9.2.5.1). 
RSN information (details specified in subclause 9.2.5.1). 
Power offset (details specified in subclause 1 1.8.1.4). 
E-TFCI (details specified in subclause 1 1.8.1.4). 

c) Relative Grant information for E-DCH: 

Serving Relative Grant information (details specified in subclause 9.2.5.2.1). 
Non-serving Relative Grant information (details specified in subclause 9.2.5.2.1). 

d) Absolute Grant information for E-DCH (details specified in subclause 9.2.5.2.2). 

- Identity Type for E-DCH. 
Absolute Grant Value. 
Absolute Grant Scope. 

e) Happy Bit (details specified in subclause 9.2.5.2.2). 



8.2 



Primitives between IVIAC and RLC 



8.2.1 Primitives 

The primitives between MAC layer and RLC layer are shown in table 8.2.1.1. 

Table 8.2.1.1 : Primitives between MAC layer and RLC layer 



Generic Name 


Parameter 


Request 


Indication 


Response 


Confirm 


MAC-DATA 


Data, BO, UE-ID type 

indicator, RLC Entity 

Info 


Data, No_TB, 

TD (note). Error 

indication 






MAC-STATUS 




No_PDU, PDU_Size, 

TX status. 
Status Report REO 


BO, 
RLC Entity Info 




NOTE: TDD only. 



MAC-DATA-Req/Ind: 

MAC-DATA-Req primitive is used to request that an upper layer PDU be sent using the procedures for the 
information transfer service; 
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MAC-DAT A-Ind primitive indicates the arrival of upper layer PDUs received within one transmission time 
interval by means of the information transfer service. 

MAC-STATUS-Ind/Resp: 

MAC-STATUS-Ind primitive indicates to RLC for each logical channel the rate at which it may transfer data to 
MAC. Parameters are the number of PDUs that can be transferred in each transmission time interval and the 
PDU size; it is possible that MAC would use this primitive to indicate that it expects the current buffer 
occupancy of the addressed logical channel in order to provide for optimised TFC selection on transport 
channels with long transmission time interval. At the UE, MAC-STATUS-Ind primitive is also used to indicate 
from MAC to RLC that MAC has requested data transmission by PHY (i.e. PHY-DATA-REQ has been 
submitted, see Fig. 1 1.2.2.1), or that transmission of an RLC PDU on RACH has failed due to exceeded 
preamble ramping cycle counter. 

- MAC-STATUS-Resp primitive enables RLC to acknowledge a MAC-STATUS-Ind. It is possible that RLC 
would use this primitive to indicate that it has nothing to send or that it is in a suspended state or to indicate the 
current buffer occupancy to MAC. 

8.2.2 Parameters 

a) Data: 

it contains the RLC layer messages (RLC -PDU) to be transmitted, or the RLC layer messages that have been 
received by the MAC sub-layer. 

b) Number of transmitted transport blocks (No_TB) : 

indicates the number of transport blocks transmitted by the peer entity within the transmission time interval, 
based on the TFI value. 

c) Buffer Occupancy (BO): 

the parameter Buffer Occupancy (BO) indicates for each logical channel the amount of data in number of 
bytes that is available for transmission and retransmission in RLC layer. When MAC is connected to an AM 
RLC entity, control PDUs to be transmitted and RLC PDUs outside the RLC Tx window shall also be 
included in the BO. RLC PDUs that have been transmitted but not negatively acknowledged by the peer 
entity shall not be included in the BO. 

d) RX Timing Deviation (TD), TDD only: 

it contains the RX Timing Deviation as measured by the physical layer for the physical resources carrying the 
data of the Message Unit. This parameter is optional and only for Indication. It is needed for the transfer of 
the RX Timing Deviation measurement of RACH transmissions carrying CCCH data to RRC. 

e) Number of PDU (No_PDU): 

specifies the number of PDUs that the RLC is permitted to transfer to MAC within a transmission time 
interval. 

f) PDU Size (PDU_Size): 

specifies the size of PDU that can be transferred to MAC within a transmission time interval. 

g) UE-ID Type Indicator: 

indicates the UE-ID type to be included in MAC for a DCCH and DTCH when they are mapped onto a 
common transport channel (i.e. EACH, RACH in EDD). On the UE side UE-ID Type Indicator shall always 
be set to C-RNTI. 

h) TX status: 

when set to value "transmission unsuccessful" this parameter indicates to RLC that transmission of an RLC 
PDU failed in the previous Transmission Time Interval, when set to value "transmission successful" this 
parameter indicates to RLC that the requested RLC PDU(s) has been submitted for transmission by the 
physical layer. 
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i) RLC Entity Info 

indicates to MAC the configuration parameters that are critical to TFC selection depending on its mode and 
the amount of data that could be transmitted at the next TTI. This primitive is meant to insure that MAC can 
perform TFC selection (see subclause 1 1.4). 

j) Error indication 



When a MAC SDU is delivered to upper layer, an error indication is given for the SDU to upper layer if an 
error indication for the SDU has been received from lower layer. 

k) Status_Report_REQ 

indicates to all AM RLC entities mapped on HS-DSCH to generate a status report when the MAC-hs resets. 



8.3 



Primitives between IVIAC and RRC 



8.3.1 Primitives 

The primitives between MAC and RRC are shown in table 8.3.1.1. 

Table 8.3.1.1 : Primitives between MAC sub-layer and RRC 



Generic Name 


Parameter 


Request 


Indication 


Response 


Confirm 


CIVIAC-CONFIG 


UE information elements, 

RB information elements, 

TrCH information elements, 

RACH transmission control elements, 

Ciphering elements, 

MBMS information elements, 

E-DCH configuration elements 








CIVIAC- 
MEASUREMENT 


Measurement information elements 


IVIeasurement 
result 






CIVIAC-STATUS 




Status info 







CMAC-CONFIG-Req: 

CMAC-CONFIG-Req is used to request for setup, release and configuration of a logical channel, e.g. RNTI 
allocation, switching the connection between logical channels and transport channels, TECS update or 
scheduling priority of logical channel. 

CMAC-MEASUREMENT-Req/Ind: 

CMAC-MEASUREMENT-Req is used by RRC to request MAC to perform measurements, e.g. traffic volume 
measurements; 

- CMAC-MEASUREMENT-Ind is used to notify RRC of the measurement result. 
CMAC-STATUS-Ind: 

- CMAC-STATUS-Ind primitive notifies RRC of status information. 

8.3.2 Parameters 

See [7] for a detailed description of the UE, RB and TrCH information elements. 

a) UE information elements 
S-RNTI 
SRNC identity 
C-RNTI 
Activation time 
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Primary E-RNTI configured 
Secondary E-RNTI configured 

b) RB information elements 

RB multiplexing info (Transport channel identity, Logical channel identity, MAC logical channel priority) 

DDI mapping table for E-DCH transmission 

Indication whether the Logical channel is considered when the Scheduling Information is generated 

c) TrCH information elements 
Transport Format Combination Set 
MAC-hs reset indicator 
MAC-es/e reset indicator 
Re-ordering release timer (Tl) 

HARQ Profile parameters (power offset, maximum number of re-transmissions) 

E-DCH TTI duration 

Allowed combinations for multiplexing of MAC-d flows into MAC-e PDUs 

E-DCH grant type of MAC-d flows (scheduled or non-scheduled) 

List of HARQ processes on which non-scheduled grants are allowed (if the grant type is non-scheduled and the 

E-DCH TTI duration is 2ms) 

d) Measurement information elements 
Reporting Quantity identifiers 

Time interval to take an average or a variance (applicable when Average or Variance is Reporting Quantity) 

e) Measurement result 
Reporting Quantity 

f) Status info 

when set to value "transmission unsuccessful" this parameter indicates to RRC that transmission of a TM RLC 
PDU failed (due to e.g. Maximum number of preamble ramping cycles reached for RACH in FDD), when set to 
value "transmission successful" this parameter indicates to RRC that the requested TM RLC PDU(s) has been 
submitted for transmission by the physical layer. 

g) RACH transmission control elements 

Set of ASC parameters (identifier for PRACH partitions, persistence values) 

Maximum number of preamble ramping cycles (FDD) or synchronisation attempts (1.28 Mcps TDD) M^ax 

Minimum and maximum number of time units between two preamble ramping cycles, NBoimin and Neoimax (FDD 

only) 

ASC for RRC CONNECTION REQUEST message 

h) Ciphering elements 
Ciphering mode 
Ciphering key 
Ciphering sequence number 

i) (Void) 

j) MBMS information elements 
MEMS Id 

k) E-DCH configuration elements 
E-DPCCH to DPCCH power offset 
Happy bit delay condition 
E-TFCI table index 
minimum set E-TFCI 
Reference E-TFCI 

Periodicities for Scheduling Information with and without grant 
Scheduling Information power offset 

List of HARQ processes on which scheduled grants are allowed (if the E-DCH TTI duration is 2ms) 
Initial Serving Grant value and type 
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9 Elements for peer-to-peer communication 

9.1 Protocol data units 

9.1.1 General 

A MAC PDU is a bit string, with a length not necessarily a multiple of 8 bits. In the drawings in clause 9.1, bit strings 
are represented by tables in which the first bit is the leftmost one on the first line of the table, the last bit is the rightmost 
on the last line of the table, and more generally the bit string is to be read from left to right and then in the reading order 
of the lines. 

Depending on the provided service, MAC SDUs are bit strings with any non-null length, or bit strings with an integer 
number of octets in length. An SDU is included into a MAC PDU from first bit onward. 

In the UE for the uplink, all MAC PDUs delivered to the physical layer within one TTI are defined as Transport Block 
Set (TBS). It consists of one or several Transport Blocks, each containing one MAC PDU. The Transport Blocks, shall 
be transmitted in the order as delivered from RLC. When multiplexing of RLC PDUs from different logical channels is 
performed on MAC, the order of all Transport Blocks originating from the same logical channel shall be the same as the 
order of the sequence delivered from RLC. The order of the different logical channels in a TBS is set by the MAC 
protocol. 

9.1 .2 MAC PDU (not HS-DSCH or E-DCH) 

A MAC PDU consists of an optional MAC header and a MAC Service Data Unit (MAC SDU), see figure 9.1.2.1. Both 
the MAC header and the MAC SDU are of variable size. 

The content and the size of the MAC header depends on the type of the logical channel, and in some cases none of the 
parameters in the MAC header are needed. 

The size of the MAC-SDU depends on the size of the RLC-PDU, which is defined during the setup procedure. 



MAC header MAC SDU 
< M ► 



TCTF 


UE-ld 
type 


UE-ld or 
MBMS-ld 


C/T 


MAC SDU 



Figure 9.1.2.1: MAC PDU 

9.1 .3 MAC-d PDU (HS-DSCH) 

For HS-DSCH the MAC-d PDU format equals the MAC PDU format for the non HS-DSCH case. 

9.1.4 MAC PDU (HS-DSCH) 

In case of HS-DSCH a MAC PDU consists of one MAC-hs header and one or more MAC-hs SDUs where each MAC- 
hs SDU equals a MAC-d PDU. A maximum of one MAC-hs PDU can be transmitted in a TTI per UE. The MAC-hs 
header is of variable size. The MAC-hs SDUs in one TTI belongs to the same reordering queue. 
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VF 


Queue ID 


TSN 


SIDi 


Ni 


Fi 


SID2 


N2 


F2 



SIDk 


Nk 


Fk 



MAC-hs header 



MAC-hs SDU 



MAC-hs SDU 



Padding (opt) 



Mac-hs payload 



Figure 9.1 .4.1 : MAC-hs PDU 

9.1.5 MAC PDU (E-DCH) 

In the case of E-DCH there are two MAC sublayers, MAC-e and MAC-es. MAC-es sits on top of MAC-e and receives 
PDUs directly from MAC-d. MAC-es SDUs (i.e. MAC-d PDUs) of the same size, coming from a particular logical 
channel are multiplexed together into a single MAC-es payload. There is one and only one MAC-es PDU per logical 
channel per TTI (since only one MAC-d PDU size is allowed per logical channel per TTI). To this payload is prepended 
the MAC-es header (see subclause 9.2.4.1). The number of PDUs, as well as the one DDI value identifying the logical 
channel, the MAC-d flow and the MAC-es SDU size are included as part of the MAC-e header. In case sufficient space 
is left in the E-DCH transport block or if Scheduling Information needs to be transmitted, an SI will be included at the 
end of the MAC-e PDU (see subclause 9.2.4.2). Multiple MAC-es PDUs from multiple logical channels, but only one 
MAC-e PDU can be transmitted in a TTI. 

In the example MAC-e PDU shown in figure 9.1.5.2a, the field DDIq is referring to the specific DDI value that indicates 
that there is an SI included in the MAC-e PDU (see subclause 9.2.4.2). This header will not be associated with a new 
MAC-es payload. Figure 9.1.5.2b shows the MAC-e PDU format when SI is sent alone. In this case DDIq is not 
included in the MAC-e PDU and E-TFCI value is used. 



MAC-d PDUs coming from one Logical Channel 



MAC-d PDU 



MAC-d PDU 



\ 






DDIl 


Nl 



TSNl MAC-es SDU MAC-es SDU MAC-es SDU 



MAC-d PDU 



Nl MAC-es SDUs of size and LCh indicated by DDIl 
•4 ► 



MAC-es PDUl 



Figure 9.1.5.1 IVIAC-es PDU 
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DDL N 



MAC-es PDUi 



DDI2 


N2 



MAC-es PDU 



DDL N„ MAC-es PDU, 







^' 






if' 






if' \ 


■-■'■'' ,'-^' 




^ ■ ^ ' / 

/ 
/ 
/" 
/* 

/ 
/* 
/' 
/' 
/ 
/' 


/ 

/ 
/ 
/ 
/ 


/ 
/ 
/ 
/ 
/ 
/ 
/' 


DDIi 


N, 


DDI2 


N2 





DDI„ 


N„ 


DDIo 
(Opt) 


MAC-es PDUi 


MAC-es PDU2 




MAC-es PDU„ 


SI 
(Opt) 


Padding 
(Opt) 





MAC-e PDU 
Figure 9.1.5.2a: MAC-e PDU 



SI 



MAC-e PDU 



Figure 9.1.5.2b: IVIAC-e PDU (SI is sent alone) 



9.2 Formats and parameters 



NOTE: MAC header field encodings as specified in tWs clause with designation "Reserved" are forbidden to be 
used by a sender in this version of the protocol. 

9.2.1 MAC PDU: Parameters of the MAC PDU header (not HS-DSCH or 
E-DCH) and MAC-d PDU header (HS-DSCH and E-DCH) 

The following fields are defined for the MAC header for transport charmels other than HS-DSCH and for the MAC-d 
PDU header for HS-DSCH: 

Target Channel Type Field 

The TCTF field is a flag that provides identification of the logical channel class on FACH, USCH (TDD only), 
DSCH (TDD only) and RACH transport channels, i.e. whether it carries BCCH, CCCH, CTCH, SHCCH, 
MCCH, MTCH, MSCH or dedicated logical channel information. The size and coding of TCTF for FDD and 
TDD are shown in tables 9.2.1.1, 9.2.1.2, 9.2.1.3, 9.2.1.4 and 9.2.1.5. Note that the size of the TCTF field of 
FACH for FDD is 2,4 or 8 bits and for TDD is either 3 or 5 bits depending on the value of the 3 most significant 
bits. The TCTF of the RACH for TDD is either 2 or 4 bits depending on the value of the 2 most significant bits. 
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Table 9.2.1.1 : Coding of the Target Channel Type Field on FACH for TDD 



TCTF 


Designation 


000 


BCCH 


001 


CCCH 


010 


CTCH 


01100 


DCCH or DTCH 
over FACH 


01101 


MCCH 


01110 


MTCH 


01111 


MSCH 


100 


SHCCH 


101-111 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 



Table 9.2.1.2: Coding of the Target Channel Type Field on FACH for FDD 



TCTF 


Designation 


00 


BCCH 


01000000 


CCCH 


01000001- 
01001111 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 


01010000 


MCCH 


01010001- 
01011110 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 


01011111 


MSCH 


0110 


MTCH 


0111 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 


10000000 


CTCH 


10000001- 
10111111 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 


11 


DCCH or DTCH 
over FACH 



Table 9.2.1.3: Coding of the Target Channel Type Field on USCH or DSCH (TDD only) 



TCTF 


Designation 





SHCCH 


1 


DCCH or DTCH over 
USCH or DSCH 
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Table 9.2.1.4: Coding of the Target Channel Type Field on RACH for FDD 



TCTF 


Designation 


00 


CCCH 


01 


DCCH or DTCH 
over RACH 


10-11 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 



Table 9.2.1.5: Coding of the Target Channel Type Field on RACH for TDD 



TCTF 


Designation 


00 


CCCH 


0100 


DCCH or DTCH 
Over RACH 


0101- 
0111 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 


10 


SHCCH 


11 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 



C/T field 

The C/T field provides identification of the logical channel instance when multiple logical channels are carried 
on the same transport channel (other than HS-DSCH) or same MAC-d flow (HS-DSCH). The C/T field is used 
also to provide identification of the logical channel type on dedicated transport channels and on FACH and 
RACH when used for user data transmission. The size of the C/T field is fixed to 4 bits for both common 
transport channels and dedicated transport channels. Table 9.2.1.5a shows the 4-bit C/T field. 

Table 9.2.1.5a: Structure of the C/T field 



C/T field 


Designation 


0000 


Logical channel 1 


0001 


Logical channel 2 






1110 


Logical channel 15 


1111 


Reserved 

(PDUs with this coding will be 

discarded by this version of 

the protocol) 



UE-Id 

The UE-Id field provides an identifier of the UE on common transport charmels. The following types of UE-Id 

used on MAC are defined: 

- UTRAN Radio Network Temporary Identity (U-RNTI) may be used in the MAC header of DCCH using 
RLC UM (SRBl), when mapped onto common transport channels in downlink direction; the U-RNTI is 
never used in uplink direction; 

Cell Radio Network Temporary Identity (C-RNTI) is used on DTCH and DCCH in uplink, and may be used 
on DCCH in downlink and is used on DTCH in downlink when mapped onto common transport channels, 
except when mapped onto DSCH transport channel in TDD; 
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Table 9.2.1.6: Lengths of UE Id field 



UE Id type 


Length of UE Id field 


U-RNTI 


32 bits 


C-RNTI 


16 bits 



UE-Id Type 

The UE-Id Type field is needed to ensure correct decoding of the UE-Id field in MAC Headers. 

Table 9.2.1.7: UE-Id Type field definition 



UE-Id Type field 2 bits 


UE-Id Type 


00 


U-RNTI 


01 


C-RNTI 


10 


Reserved 

(PDUs with this coding will be 

discarded by this version of 

the protocol) 


11 


Reserved 

(PDUs with this coding will be 

discarded by this version of 

the protocol) 



MBMS-Id 

The MBMS-Id field provides an identifier of MTCH for an MEMS service carried on EACH. The MBMS- 
Id is used in the MAC header of MTCH mapped onto EACH in downlink direction; the MBMS-Id is never 
used in uplink direction. The MBMS Id to be used by MAC is configured through the MAC control SAP. 
The length of the MBMS-Id field is 4 bits. Table 9.2.1.7a shows the 4-bit MBMS-Id field. 

Table 9.2.1.8: Structure of the MBMS-Id field 



MBMS-Id 
field 


MBMS logical channel 
identity [7] 


0000 


1 


0001 


2 






1110 


15 


1111 


Reserved 

(PDUs with this coding will be 

discarded by this version of 

the protocol) 



9.2.1 .1 MAC header for DTCH and DCCH (not mapped on HS-DSCH or E-DCH) 

a) DTCH or DCCH mapped to DCH, no multiplexing of dedicated channels on MAC: 

no MAC header is required. 

b) DTCH or DCCH mapped to DCH, with multiplexing of dedicated channels on MAC: 

- C/T field is included in MAC header. 

c) DTCH or DCCH mapped to RACH/FACH: 

- TCTE field, C/T field, UE-Id type field and UE-Id are included in the MAC header. Eor EACH, the UE-Id 
type field used is the C-RNTI or U-RNTI. Eor RACH, the UE-Id type field used is the C-RNTI. 

d) DTCH or DCCH mapped to DSCH or USCH: 

the TCTE field is included in the MAC header. The C/T field is included if multiplexing on MAC is applied. 

e) DTCH or DCCH mapped to DSCH or USCH where DTCH or DCCH are the only logical channels: 

- The C/T field is included in the MAC header if multiplexing on MAC is applied. 
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Case a): 








MAC SDU 










Case b): 




C/T 


MAC SDU 










ase c): 


TCTF 


UE-ld 
type 


UE-ld 


C/T 


MAC SDU 












Case d): 


TCTF 1 C/T 
1 


MAC SDU 






C/T 




Case e): 


MAC SDU 



Figure 9.2.1 .1 .1 : MAC PDU formats for DTCH and DCCH 



9.2.1 .1a MAC-d Header for DTCH and DCCH (mapped on HS-DSCH) 

The MAC-d PDU header for DTCH and DCCH mapped on HS-DSCH is as shown in figure 9.2.1. la.l. 
- C/T field is included in the MAC-d PDU header if multiplexing on MAC is applied. 



i C/T 



MAC SDU 



Figure 9.2.1. la.l IVIAC-d PDU format for DTCH and DCCH mapped on HS-DSCH 



9.2.1 .1 b MAC-d Header for DTCH and DCCH (mapped on E-DCH) 

For DTCH and DCCH mapped on E-DCH there is no need for a MAC-d header. Therefore, the MAC-d PDU is as 
shown in figure 9.2.1.1b.l. 



MAC SDU 



Figure 9.2.1. Ib.1 IVIAC-d PDU format for DTCH and DCCH mapped on E-DCH 

9.2.1 .2 MAC header for BCCH 

a) BCCH mapped to BCH: 

no MAC header is included. 

b) BCCH mapped to FACH: 

- the TCTF field is included in MAC header. 
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Case a): 



Case b): 



MAC SDU 



TCTF 



MAC SDU 



Figure 9.2.1 .2.1 : MAC PDU formats for BCCH 



9.2.1.3 MAC header for PCCH 

There is no MAC header for PCCH. 

9.2.1.4 MAC header for CCCH 

CCCH mapped to RACH/FACH: 

- TCTF field is included in MAC header. 



TCTF 



MAC SDU 



Figure 9.2.1.4.1: IVIAC PDU formats for CCCH 

9.2.1 .5 MAC Header for CTCH 

The TCTF field is included as MAC header for CTCH as shown in figure 9.2.1.5.1. 



TCTF 



MAC SDU 



Figure 9.2.1.5.1 : IVIAC PDU format for CTCH 

9.2.1.6 MAC Header for SHCCH 

The MAC header for SHCCH is as shown in figure 9.2.1.6.1. 

a) SHCCH mapped to RACH and USCH/FACH and DSCH: 

TCTF has to be included. 

b) SHCCH mapped to RACH and USCH/FACH and DSCH, where SHCCH is the only channel. 



Case a): 



Case b): 



TCTF 



MAC SDU 



MAC SDU 



Figure 9.2.1 .6.1 : MAC PDU format for SHCCH 

9.2.1.7 MAC Header for MCCH 

The MAC PDU format for MCCH is as shown in figure 9.2.1.7.1. 

a) If the MAC header for MCCH is not configured through the MAC control SAP; 
- there is no MAC header for MCCH. 

b) If the MAC header for MCCH is configured through the MAC control SAP: 
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- TCTF field is included in the MAC header for MCCH. 
NOTE: If MCCH is not the only channel on the FACH, the MAC header shall be configured for the MCCH. 



Case a): 



MAC SDU 



Case b): 



TCTF 



MAC SDU 



Figure 9.2.1 .7.1 : MAC PDU format for MCCH 



9.2.1 .8 MAC Header for MTCH 

The TCTF field and MBMS-Id field are included in the MAC header for MTCH as shown in figure 9.2.1.8.1. 



TCTF 


MBMS-Id 


MAC SDU 



Figure 9.2.1.8.1: MAC PDU format for MTCH 

9.2.1.9 MAC Header for MSCH 

The MAC PDU format for MSCH is as shown in figure 9.2.1.9.1. 

a) If the MAC header for MSCH is not configured through the MAC control SAP: 

- there is no MAC header for MSCH. 

b) If the MAC header for MSCH is configured through the MAC control SAP: 

- TCTF field is included in the MAC header for MSCH. 

NOTE: If MSCH is not the only channel on the FACH, the MAC header shall be configured for the MSCH. 



Case a): 



Case b): 



MAC SDU 



TCTF 



MAC SDU 



Figure 9.2.1.9.1: MAC PDU format for MSCH 

9.2.2 MAC PDU: Parameters of the MAC header (HS-DSCH) 

Version Flag (VF): 

The VF field is a one bit flag providing extension capabilities of the MAC-hs PDU format. The VF field shall be 

set to zero and the value one is reserved in this version of the protocol. 

Queue identifier (Queue ID): 

The Queue ID field provides identification of the reordering queue in the receiver, in order to support 

independent buffer handling of data belonging to different reordering queues. The length of the Queue ID field is 

3 bit. 

Transmission Sequence Number (TSN): 

The TSN field provides an identifier for the transmission sequence number on the HS-DSCH. The TSN field is 
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used for reordering purposes to support in-sequence delivery to higher layers. The length of the TSN field is 6 
bit. 

Size index identifier (SID): 

The SID fields identifies the size of a set of consecutive MAC-d PDUs. The MAC-d PDU size for a given SID is 

configured by higher layers and is independent for each Queue ID. The length of the SID field is 3 bit. 

- Number of MAC-D PDUs (N) : 

The number of consecutive MAC-d PDUs with equal size is identified with the N field. The length of the N field 
is 7 bits. In FDD mode, the maximum number of PDUs transmitted in a single TTI shall be assumed to be 70. In 
1.28 Mcps TDD mode, the maximum number of PDUs transmitted in a single TTI shall be assumed to be 45. In 
3.84 Mcps TDD mode, the maximum number of PDUs transmitted in a single TTI shall be assumed to be 318. If 
more PDUs than the defined maximum number of PDUs for the corresponding mode are received, the UE 
behaviour is unspecified. 

- Flag(F): 

The F field is a flag indicating if more fields are present in the MAC-hs header or not. If the F field is set to "0" 
the F field is followed by an additional set of SID, N and F fields. If the F field is set to "1" the F field is 
followed by a MAC-d PDU. The maximum number of MAC-hs header extensions, i.e. number of fields F set to 
"0", in a single TTI shall be assumed to be 7. If more extensions than the maximum defined for the 
corresponding mode are included in a TTI, the UE behaviour is unspecified. 

9.2.2.1 MAC header for DTCH and DCCH 

a) DTCH or DCCH mapped to HS-DSCH: 

The Queue ID field and TSN field are always included in the MAC-hs header. One SID field, N field and F 
field is included for each MAC-d PDU size included in the MAC-hs PDU. Padding is not explicitly indicated 
but is included in the end of the MAC-hs PDU if the total size of the MAC-hs payload plus the MAC-hs 
header is smaller than the transport block set size. 

9.2.3 Signalling of Transport Block size for HS-DSCH 

For HS-DSCH the transport block size is derived from the TFRI value signalled on the HS-SCCH. The mapping 
between the TFRI value and the transport block size for each mode is specified below: 

9.2.3.1 Transport block size for FDD 

For all transmissions of a transport block, the transport block size is derived from the TFRI value as specified below, 
except only in those cases of retransmissions where the Node-B selects a combination for which no mapping exists 
between the original transport block size and the selected combination of channelisation Code set and modulation type. 
In such cases, the transport block size index value signalled to the UE shall be set to 11 11 1 1, i.e., ki=63. 

Let /(/be the TFRI signalled on the HS-SCCH value and let kojhe the value in the table 9.2.3.1 corresponding to the 
modulation and the number of codes signalled on the HS-SCCH. Let kf be the sum of the two values: kf = k, + kgj. The 
transport block size L(kt) can be obtained by accessing the position kf in the table in Annex A (normative) or by using 
the formula below (informative): 

If /((<40 

L(k,) = 125 + 12- k, 

else 

p = 2085/2048 
^™„ = 296 
end 
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Table 9.2.3.1 : Values of koiior different numbers of channelization codes and modulation schemes 



Combination / 


Modulation 
scheme 


Number of 
channelization codes 


^0,, 





QPSK 


1 


1 


1 


2 


40 


2 


3 


63 


3 


4 


79 


4 


5 


92 


5 


6 


102 


6 


7 


111 


7 


8 


118 


8 


9 


125 


9 


10 


131 


10 


11 


136 


11 


12 


141 


12 


13 


145 


13 


14 


150 


14 


15 


153 


15 


16QAM 


1 


40 


16 


2 


79 


17 


3 


102 


18 


4 


118 


19 


5 


131 


20 


6 


141 


21 


7 


150 


22 


8 


157 


23 


9 


164 


24 


10 


169 


25 


11 


175 


26 


12 


180 


27 


13 


184 


28 


14 


188 


29 


15 


192 



9.2.3.2 Transport block size for 3.84 Mcps TDD 

Let k be the signalled TFRI value, then the corresponding HS-DSCH transport block size Lj. is given by : 
If/t=1..510 

u=\l . p'l 

k L min r^ J 

8313 

P = 

8192 

L . =57 

mill 

Iffe = 511 

Lk= 102000 
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If k=Q, L^ indicates NULL and shall not be used to signal a transport block size in the TFRI. 
Transport block sizes calculated by this formula shall equal the values indicated in Table 9.2.3.2.1 
Table 9.2.3.2.1 : HSDPA Transport Block Sizes for 3.84 Mcps TDD 



TB index 
(k) 


TB size 
[bits] 


TB index 
(k) 


TB size 
[bits] 


TB index 
(k) 


TB size 
[bits] 


TB index 
(k) 


TB size 
[bits] 





NULL 


128 


372 


256 


2432 


384 


15890 


1 


57 


129 


377 


257 


2468 


385 


16124 


2 


58 


130 


383 


258 


2504 


386 


16362 


3 


59 


131 


389 


259 


2541 


387 


16604 


4 


60 


132 


394 


260 


2579 


388 


16849 


5 


61 


133 


400 


261 


2617 


389 


17098 


6 


62 


134 


406 


262 


2656 


390 


17351 


7 


63 


135 


412 


263 


2695 


391 


17607 


8 


64 


136 


418 


264 


2735 


392 


17867 


9 


65 


137 


424 


265 


2775 


393 


18131 


10 


66 


138 


431 


266 


2816 


394 


18399 


11 


66 


139 


437 


267 


2858 


395 


18671 


12 


67 


140 


443 


268 


2900 


396 


18946 


13 


68 


141 


450 


269 


2943 


397 


19226 


14 


69 


142 


457 


270 


2986 


398 


19510 


15 


71 


143 


463 


271 


3030 


399 


19798 


16 


72 


144 


470 


272 


3075 


400 


20091 


17 


73 


145 


477 


273 


3121 


401 


20388 


18 


74 


146 


484 


274 


3167 


402 


20689 


19 


75 


147 


491 


275 


3213 


403 


20994 


20 


76 


148 


499 


276 


3261 


404 


21304 


21 


77 


149 


506 


277 


3309 


405 


21619 


22 


78 


150 


514 


278 


3358 


406 


21938 


23 


79 


151 


521 


279 


3408 


407 


22263 


24 


81 


152 


529 


280 


3458 


408 


22591 


25 


82 


153 


537 


281 


3509 


409 


22925 


26 


83 


154 


545 


282 


3561 


410 


23264 


27 


84 


155 


553 


283 


3613 


411 


23607 


28 


85 


156 


561 


284 


3667 


412 


23956 


29 


87 


157 


569 


285 


3721 


413 


24310 


30 


88 


158 


578 


286 


3776 


414 


24669 


31 


89 


159 


586 


287 


3832 


415 


25033 


32 


91 


160 


595 


288 


3888 


416 


25403 


33 


92 


161 


604 


289 


3946 


417 


25778 


34 


93 


162 


613 


290 


4004 


418 


26159 


35 


95 


163 


622 


291 


4063 


419 


26545 


36 


96 


164 


631 


292 


4123 


420 


26938 


37 


98 


165 


640 


293 


4184 


421 


27335 


38 


99 


166 


650 


294 


4246 


422 


27739 


39 


100 


167 


659 


295 


4309 


423 


28149 


40 


102 


168 


669 


296 


4372 


424 


28565 


41 


103 


169 


679 


297 


4437 


425 


28987 


42 


105 


170 


689 


298 


4502 


426 


29415 


43 


107 


171 


699 


299 


4569 


427 


29849 
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44 


108 


172 


709 


300 


4636 


428 


30290 


45 


110 


173 


720 


301 


4705 


429 


30738 


46 


111 


174 


730 


302 


4774 


430 


31192 


47 


113 


175 


741 


303 


4845 


431 


31652 


48 


115 


176 


752 


304 


4916 


432 


32120 


49 


116 


177 


763 


305 


4989 


433 


32594 


50 


118 


178 


775 


306 


5063 


434 


33076 


51 


120 


179 


786 


307 


5138 


435 


33564 


52 


122 


180 


798 


308 


5213 


436 


34060 


53 


123 


181 


809 


309 


5290 


437 


34563 


54 


125 


182 


821 


310 


5369 


438 


35074 


55 


127 


183 


834 


311 


5448 


439 


35592 


56 


129 


184 


846 


312 


5528 


440 


36117 


57 


131 


185 


858 


313 


5610 


441 


36651 


58 


133 


186 


871 


314 


5693 


442 


37192 


59 


135 


187 


884 


315 


5777 


443 


37742 


60 


137 


188 


897 


316 


5862 


444 


38299 


61 


139 


189 


910 


317 


5949 


445 


38865 


62 


141 


190 


924 


318 


6037 


446 


39439 


63 


143 


191 


937 


319 


6126 


447 


40021 


64 


145 


192 


951 


320 


6217 


448 


40613 


65 


147 


193 


965 


321 


6308 


449 


41212 


66 


150 


194 


980 


322 


6402 


450 


41821 


67 


152 


195 


994 


323 


6496 


451 


42439 


68 


154 


196 


1009 


324 


6592 


452 


43066 


69 


156 


197 


1024 


325 


6689 


453 


43702 


70 


159 


198 


1039 


326 


6788 


454 


44347 


71 


161 


199 


1054 


327 


6889 


455 


45002 


72 


163 


200 


1070 


328 


6990 


456 


45667 


73 


166 


201 


1085 


329 


7094 


457 


46342 


74 


168 


202 


1101 


330 


7198 


458 


47026 


75 


171 


203 


1118 


331 


7305 


459 


47721 


76 


173 


204 


1134 


332 


7413 


460 


48426 


77 


176 


205 


1151 


333 


7522 


461 


49141 


78 


178 


206 


1168 


334 


7633 


462 


49867 


79 


181 


207 


1185 


335 


7746 


463 


50603 


80 


184 


208 


1203 


336 


7860 


464 


51351 


81 


186 


209 


1221 


337 


7976 


465 


52109 


82 


189 


210 


1239 


338 


8094 


466 


52879 


83 


192 


211 


1257 


339 


8214 


467 


53660 


84 


195 


212 


1276 


340 


8335 


468 


54453 


85 


198 


213 


1294 


341 


8458 


469 


55257 


86 


201 


214 


1313 


342 


8583 


470 


56073 


87 


204 


215 


1333 


343 


8710 


471 


56901 


88 


207 


216 


1353 


344 


8839 


472 


57742 


89 


210 


217 


1373 


345 


8969 


473 


58595 


90 


213 


218 


1393 


346 


9102 


474 


59460 


91 


216 


219 


1413 


347 


9236 


475 


60338 


92 


219 


220 


1434 


348 


9373 


476 


61230 


93 


222 


221 


1456 


349 


9511 


477 


62134 
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94 


226 


222 


1477 


350 


9652 


478 


63052 


95 


229 


223 


1499 


351 


9794 


479 


63983 


96 


232 


224 


1521 


352 


9939 


480 


64928 


97 


236 


225 


1543 


353 


10086 


481 


65887 


98 


239 


226 


1566 


354 


10235 


482 


66860 


99 


243 


227 


1589 


355 


10386 


483 


67848 


100 


246 


228 


1613 


356 


10539 


484 


68850 


101 


250 


229 


1637 


357 


10695 


485 


69867 


102 


254 


230 


1661 


358 


10853 


486 


70899 


103 


258 


231 


1685 


359 


11013 


487 


71946 


104 


261 


232 


1710 


360 


11176 


488 


73009 


105 


265 


233 


1736 


361 


11341 


489 


74087 


106 


269 


234 


1761 


362 


11508 


490 


75182 


107 


273 


235 


1787 


363 


11678 


491 


76292 


108 


277 


236 


1814 


364 


11851 


492 


77419 


109 


281 


237 


1840 


365 


12026 


493 


78563 


110 


285 


238 


1868 


366 


12204 


494 


79723 


111 


290 


239 


1895 


367 


12384 


495 


80901 


112 


294 


240 


1923 


368 


12567 


496 


82095 


113 


298 


241 


1952 


369 


12752 


497 


83308 


114 


303 


242 


1981 


370 


12941 


498 


84539 


115 


307 


243 


2010 


371 


13132 


499 


85787 


116 


312 


244 


2039 


372 


13326 


500 


87054 


117 


316 


245 


2070 


373 


13523 


501 


88340 


118 


321 


246 


2100 


374 


13722 


502 


89645 


119 


326 


247 


2131 


375 


13925 


503 


90969 


120 


331 


248 


2163 


376 


14131 


504 


92313 


121 


336 


249 


2195 


377 


14340 


505 


93676 


122 


340 


250 


2227 


378 


14551 


506 


95060 


123 


346 


251 


2260 


379 


14766 


507 


96464 


124 


351 


252 


2293 


380 


14984 


508 


97889 


125 


356 


253 


2327 


381 


15206 


509 


99335 


126 


361 


254 


2362 


382 


15430 


510 


100802 


127 


366 


255 


2397 


383 


15658 


511 


102000 



9.2.3.3 Transport block size for 1 .28 Mcps TDD 

The mapping of transport block size, in bits, to TFRI value is dependent upon the UE's HS-DSCH capability class. 
If k is the signalled TFRI value then the corresponding HS-DSCH transport block size Lt is given by: 
lfk= 1..62 



4=L^min/"'J 



where 



P = 



1340 
1269 



if the HS-DSCH physical layer category is between 1 and 6 inclusively. 
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P = 



p = 



1755 
1652 

2345 
2196 



if the HS-DSCH physical layer category is between 7 and 12 inclusively, 



if the HS-DSCH physical layer category is between 13 and 15 inclusively, 



and 



L„.„ = 240 



If ;t = 63 then, 

Lj. = 7008 if the HS-DSCH physical layer category is between 1 and 6 inclusively, 
10204 if the HS-DSCH physical layer category is between 7 and 12 inclusively, 
14043 if the HS-DSCH physical layer category is between 13 and 15 inclusively. 

If k=0, L^ indicates NULL and shall not be used to signal a transport block size in the TFRI. 



Transport block sizes calculated by this formula shall equal the values indicated in the following tables: - 

Table 9.2.3.3.1 : HSDPA Transport Block Sizes for 1.28 Mcps TDD, for HS-DSCH physical layer 

category [1 ,6] 



TB index (k) 


TB size 
[bits] 


TB index (k) 


TB size 
[bits] 


TB index (k) 


TB size 
[bits] 


TB index (k) 


TB size 
[bits] 





NULL 


16 


543 


32 


1297 


48 


3100 


1 


240 


17 


573 


33 


1370 


49 


3274 


2 


253 


18 


605 


34 


1446 


50 


3457 


3 


267 


19 


639 


35 


1527 


51 


3650 


4 


282 


20 


675 


36 


1613 


52 


3854 


5 


298 


21 


712 


37 


1703 


53 


4070 


6 


315 


22 


752 


38 


1798 


54 


4298 


7 


332 


23 


794 


39 


1899 


55 


4538 


8 


351 


24 


839 


40 


2005 


56 


4792 


9 


370 


25 


886 


41 


2118 


57 


5060 


10 


391 


26 


936 


42 


2236 


58 


5344 


11 


413 


27 


988 


43 


2361 


59 


5643 


12 


436 


28 


1043 


44 


2493 


60 


5958 


13 


461 


29 


1102 


45 


2633 


61 


6292 


14 


487 


30 


1163 


46 


2780 


62 


6644 


15 


514 


31 


1228 


47 


2936 


63 


7008 
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Table 9.2.3.3.2: HSDPA Transport Block Sizes for 1.28 Mcps TDD, for HS-DSCH physical layer 

category [7,12] 



TB index (k) 


TB size 
[bits] 


TB index (k) 


TB size 
[bits] 


TB index (k) 


TB size 
[bits] 


TB index (k) 


TB size 
[bits] 





NULL 


16 


594 


32 


1564 


48 


4118 


1 


240 


17 


631 


33 


1662 


49 


4375 


2 


254 


18 


671 


34 


1766 


50 


4648 


3 


270 


19 


712 


35 


1876 


51 


4938 


4 


287 


20 


757 


36 


1993 


52 


5246 


5 


305 


21 


804 


37 


2117 


53 


5573 


6 


324 


22 


854 


38 


2249 


54 


5920 


7 


344 


23 


908 


39 


2389 


55 


6289 


8 


366 


24 


964 


40 


2538 


56 


6681 


9 


389 


25 


1024 


41 


2697 


57 


7098 


10 


413 


26 


1088 


42 


2865 


58 


7541 


11 


439 


27 


1156 


43 


3043 


59 


8011 


12 


466 


28 


1228 


44 


3233 


60 


8510 


13 


495 


29 


1305 


45 


3435 


61 


9041 


14 


526 


30 


1386 


46 


3649 


62 


9605 


15 


559 


31 


1473 


47 


3877 


63 


10204 


Table 9.2.3.3.3 : HSDPA Transport Block Sizes for 1.28 lUlcps TDD, for HS-DSCH physical layer 

category [13,15] 


TB index (k) 


TB size 
[bits] 


TB index (k) 


TB size 
[bits] 


TB index (k) 


TB size 
[bits] 


TB index (k) 


TB size 
[bits] 





NULL 


16 


642 


32 


1836 


48 


5250 


1 


240 


17 


686 


33 


1961 


49 


5606 


2 


256 


18 


732 


34 


2094 


50 


5987 


3 


273 


19 


782 


35 


2236 


51 


6393 


4 


292 


20 


835 


36 


2388 


52 


6827 


5 


312 


21 


892 


37 


2550 


53 


7290 


6 


333 


22 


952 


38 


2723 


54 


7785 


7 


355 


23 


1017 


39 


2908 


55 


8313 


8 


380 


24 


1086 


40 


3105 


56 


8877 


9 


405 


25 


1160 


41 


3316 


57 


9479 


10 


433 


26 


1238 


42 


3541 


58 


10123 


11 


462 


27 


1322 


43 


3781 


59 


10809 


12 


494 


28 


1412 


44 


4037 


60 


11543 


13 


527 


29 


1508 


45 


4311 


61 


12326 


14 


563 


30 


1610 


46 


4604 


62 


13162 


15 


601 


31 


1719 


47 


4916 


63 


14043 



9.2.4 MAC PDU: Parameters of the MAC header (E-DCH) 



9.2.4.1 



MAC-es header parameters 



Transmission Sequence Number (TSN): 

The TSN field provides the transmission sequence number for the MAC-es PDU. This information is used for 

reordering purposes to support in-sequence delivery to higher layers. The length of the TSN field is 6 bits. 



9.2.4.2 



MAC-e header parameters 



Data description indicator (DDI): 

The DDI field identifies the logical channel, MAC-d flow and size of the MAC-d PDUs concatenated into the 
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associated MAC-es PDU. The mapping between the DDI values and the logical channel ID, MAC-d flow and 
PDU size is provided by higher layers. The length of the DDI field is 6 bits. When, due to the quantization in the 
transport block sizes that can be supported or triggering of the Scheduling Information, the size of the data plus 
header is less than or equal to the TB size of the E-TFC selected by the UE minus 24 bits, the DDI value 
[111111] shall be appended at the end of the MAC-e header and a Scheduling Information shall be concatenated 
into this MAC-e PDU, where DDI value [111111] indicates that there is a Scheduling Information concatenated 
in this MAC-e PDU. Otherwise, if the size of the data plus header is less than or equal to the TB size of the E- 
TFC selected by the UE minus 18 bits, a Scheduling Information shall be concatenated into this MAC-e PDU. In 
any other case it is understood that another MAC-es PDU or Scheduling Information does not fit and it is 
therefore not necessary to reserve room in the transport block for an additional DDI field. 

Number of MAC-d PDUs (N): 

The number of consecutive MAC-d PDUs corresponding to the same DDI value. The length of the N field is 6 

bits. 



9.2.5 Signaling of control information for E-DCH 



9.2.5.1 



HARQ information 



This control information is used in support of the uplink hybrid ARQ functionality. 

- ACK/NACK information: 

Transmitted on downlink on the E-HICH from each cell in the E-DCH active set, the ACK/NACK information 
indicates the successful or un-successful decoding of the corresponding uplink transmission. This information 
allows the UE to know whether to make another transmission for the same MAC-e PDU or to start the 
transmission of a new one. The length of the ACK/NACK field is 1 bit. 

- RSN: 

Transmitted on the E-DPCCH, the RSN is used to convey the uplink HARQ transmission number. Because of 
the limitation in the field size, the RSN saturates to the maximum value once that is reached. The combination of 
the RSN and the transmission timing allows the receiver to determine the exact transmission number (see [16]). 
The length of the RSN field is 2 bits. 



9.2.5.2 



DL Scheduling information 



This control information is used by Node-Bs in a UE's E-DCH active set in order to control its use of E-DCH system 
resources. 



9.2.5.2.1 



Relative Grants 



Serving Relative Grant: 

Transmitted on downlink on the E-RGCH from all cells in the serving E-DCH RLS, the serving relative grant 
allows the Node B scheduler to incrementally adjust the serving grant of UEs under its control. By definition, 
there can only be one serving relative grant command received at any one time. This indication can take three 
different values, "UP", "DOWN" or "HOLD". 

Non-serving Relative Grant: 

Transmitted on downlink on the E-RGCH from a non-serving E-DCH RL, the non-serving relative grant allows 
neighboring Node Bs to adjust the transmitted rate of UEs that are not under their control in order to avoid 
overload situations. By definition, there could be multiple non-serving relative grant commands received by 
MAC at any time. This indication can take two different values, "DOWN" or "HOLD". 

The handling of the Relative Grant signalling is based on the Scheduling Grant table shown in Table 9.2.5.2.1.1. 

Table 9.2.5.2.1.1 : Scheduling Grant Table (SG-table) 



Index 


Scheduled 
Grant 


37 


(168/15)'*6 


36 


(150/15)'*6 


35 


(168/15)'*4 
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34 


(150/15)'*4 


33 


(134/15)'*4 


32 


(119/15)'*4 


31 


(150/15)''*2 


30 


(95/1 5)''*4 


29 


(168/15)'' 


28 


(150/15)'' 


27 


(134/15)' 


26 


(119/15)' 


25 


(106/15)' 


24 


(95/15)' 


23 


(84/15)' 


22 


(75/15)' 


21 


(67/15)' 


20 


(60/15)' 


19 


(53/15)' 


18 


(47/15)' 


17 


(42/15)' 


16 


(38/15)' 


15 


(34/15)' 


14 


(30/15)' 


13 


(27/15)' 


12 


(24/15)' 


11 


(21/15)' 


10 


(19/15)' 


9 


(17/15)' 


8 


(15/15)' 


7 


(13/15)' 


6 


(12/15)' 


5 


(11/15)' 


4 


(9/15)' 


3 


(8/15)' 


2 


(7/15)' 


1 


(6/15)' 





(5/15)' 



When the Serving_Grant needs to be determined due to E-RGCH signalling (see subclause 11. 8. 1.3.2), the UE shall: 

Determine the lowest power ratio in the SG-table (table 9.2.5.2. 1.1) that is equal or higher to the 
reference_ETPR, and determine the corresponding index in the SG-table: SGlupr; 

If the UE received a Serving Relative Grant "UP", based on the thresholds "3-index-step threshold" and "2- 
index-step threshold" configured by higher layers, determine the Serving_Grant as follows: 

if SGlupr < "3-index-step threshold": 

- Serving_Grant = SG[MIN(SGlupr + 3 , 37)]. 

if "3-index-step threshold" <= SGlupr < "2-index-step threshold": 

- Serving_Grant = SG[MIN(SGlupr + 2 , 37)] . 
if "2-index-step threshold" <= SGlupr- 

- Serving_Grant = SG[MIN(SGlupr + 1 , 37)]. 

If the UE received a Serving Relative Grant "DOWN", determine the Serving_Grant: 

- Serving_Grant = SG[MAX(SGlupr -1 , 0)]. 

If the UE received a Non-serving Relative Grant "DOWN", determine the Serving_Grant: 
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- Serving_Grant = SG[MAX(SGlupr -1,0)]. 

9.2.5.2.2 Absolute Grant 

The absolute grant message is sent on downlink, on the configured E-AGCH, from the serving E-DCH cell and allows 
the Node B scheduler to directly adjust the granted rate of UEs under its control. 

The E-AGCH is a shared channel that uses an E-RNTI specific CRC in order to address messages to specific users (see 
[6]). The RRC may configure the MAC-e with two different E-RNTIs, one primary and one secondary. Based on the 
identity that is used, the following information will be conveyed implicitly when an absolute grant message is received: 

Identity Type: 

This variable will take the value "Primary" or "Secondary" respectively based on whether the message was 

addressed to the primary or the secondary E-RNTI. 

The absolute grant message itself includes multiple fields that are multiplexed together into 6 bits inside the MAC-e of 
the Node B and then submitted to the physical layer for transmission on the E-AGCH. These fields are: 

Absolute Grant Value: 

This field indicates the maximum E-DCH traffic to pilot ratio (E-DPDCH/DPCCH) that the UE is allowed to use 

in the next transmission. The length of the Absolute Grant Value field is 5 bits. 

- Absolute Grant Scope: 

This field indicates the applicability of the Absolute Grant. It can take two different values, "Per HARQ process" 
or "All HARQ processes", allowing to indicate whether the HARQ process activation/de-activation will affect 
one or all processes. The Absolute Grant Scope is encoded in 1 bit. When the E-DCH is configured with 10ms 
TTI, only the value "All HARQ processes" is valid (see subclause 10). In case Identity Type is "Secondary", 
only the value "All HARQ processes" is valid in this version of the protocol. 

9.2.5.3 UL Scheduling information 

This control information is used by UEs to indicate to their serving E-DCH Node-B the amount of resources they 
require. 

9.2.5.3.1 Happy Bit 

The happy bit is a single bit field that is passed from MAC to the physical layer for inclusion on the E-DPCCH. This 
field takes two values, "Not Happy" and "Happy" indicating respectively whether the UE could use more resources or 
not. The setting of the Happy Bit is defined in subclause 11 .8. 1 .5. 

9.2.5.3.2 Scheduling Information 

The Scheduling Information is located at the end of the MAC-e PDU and is used to provide the serving Node B with a 
better view of the amount of system resources needed by the UE and the amount of resources it can actually make use 
of. The transmission of this information will be initiated due to the quantization of the transport block sizes that can be 
supported or based on the triggers defined in subclause 11. 8. 1.6. When a Scheduling Information is transmitted, its 
contents shall always be updated in new transmissions with the buffer status after application of the E-TFC selection 
procedure described in subclause 11.8.1.4. The logical channels for which a non-scheduled grant is configured shall 
never be taken into account when putting together this information. In addition, the RRC may restrict applicability for 
logical channels for which no non-scheduled grant was configured. 

This information includes the following fields: 

Highest priority Logical channel ID (HLID): 

The HLID field identifies unambiguously the highest priority logical channel with available data. If multiple 
logical channels exist with the highest priority, the one corresponding to the highest buffer occupancy will be 
reported. The length of the HLID is 4 bits. In case the TLBS is indicating index (0 byte), the HLID shall 
indicate the value "0000". 

Fields related to amount of available data: 

- Total E-DCH Buffer Status (TLBS): 

The TLBS field identifies the total amount of data available across all logical channels for which reporting has 
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been requested by the RRC and indicates the amount of data in number of bytes that is available for transmission 
and retransmission in RLC layer. When MAC is connected to an AM RLC entity, control PDUs to be 
transmitted and RLC PDUs outside the RLC Tx window shall also be included in the TLBS. RLC PDUs that 
have been transmitted but not negatively acknowledged by the peer entity shall not be included in the TEBS. 

The length of this field is 5 bits. The values taken by TEBS are shown in Table 9.2.5.3.2. L 

Table 9.2.5.3.2-1 : TEBS Values 



Index 


TEBS Value (bytes) 





TEBS = 


1 


0<TEBS<10 


2 


10 < TEBS < 14 


3 


14 < TEBS < 18 


4 


18 < TEBS < 24 


5 


24 < TEBS < 32 


6 


32 < TEBS < 42 


7 


42 < TEBS < 55 


8 


55 < TEBS < 73 


9 


73 < TEBS < 97 


10 


97 < TEBS < 129 


11 


129 < TEBS < 171 


12 


171 < TEBS < 228 


13 


228 < TEBS < 302 


14 


302 < TEBS < 401 


15 


401 < TEBS < 533 


16 


533 < TEBS < 708 


17 


708 < TEBS < 940 


18 


940 < TEBS < 1 248 


19 


1 248 < TEBS < 1658 


20 


1658 < TEBS < 2202 


21 


2202 < TEBS < 2925 


22 


2925 < TEBS < 3884 


23 


3884 < TEBS < 51 60 


24 


5160 < TEBS < 6853 


25 


6853 < TEBS < 91 03 


26 


91 03 < TEBS < 12092 


27 


12092 < TEBS < 16062 


28 


16062 < TEBS < 21335 


29 


21335 < TEBS < 28339 


30 


28339 < TEBS < 37642 


31 


37642 < TEBS 



Highest priority Logical channel Buffer Status (HLBS): 

The HLBS field indicates the amount of data available from the logical channel identified by HLID, relative to 
the highest value of the buffer size range reported by TEBS when the reported TEBS index is not 31, and 
relative to 50000 bytes when the reported TEBS index is 3L The length of HLBS is 4 bits. The values taken by 
HLBS are shown in table 9.2.5.3.2.2. In case the TEBS field is indicating index (0 byte), the HLBS field shall 
indicate index 0. 
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Table 9.2.5.3.2-2: HLBS Values 



Index 


HLBS values (%) 





0<HLBS<4 


1 


4 < HLBS < 6 


2 


6 < HLBS < 8 


3 


8 < HLBS < 10 


4 


10 < HLBS < 12 


5 


12 < HLBS < 14 


6 


14<HLBS<17 


7 


17 < HLBS < 21 


8 


21 < HLBS < 25 


9 


25 < HLBS < 31 


10 


31 < HLBS < 37 


11 


37 < HLBS < 45 


12 


45 < HLBS < 55 


13 


55 < HLBS < 68 


14 


68 < HLBS < 82 


15 


82 < HLBS 



UE Power Headroom (UPH): 

The UPH field indicates the ratio of the maximum UE transmission power and the corresponding DPCCH code 

power defined in [17]. The length of UPH is 5 bits. 

The Scheduling Information message is represented in figure 9.2.5.3.2-1 where for each field, the LSB is the rightmost 
bit in the figure and the MSB is the leftmost bit. 



UPH 
(5bits) 


TEBS 

(5bits) 


HLBS 
(4 bits) 


HUD 
(4 bits) 



Figure 9.2.5.3.2-1 : Scheduling Information format 

9.2.5.4 Transport block size 

RRC can configure the MAC-e to use one of two Transport block size sets for each TTI duration. The normative 
description of the mapping between the E-TFCI and the corresponding transport block size is provided in Annex B: 

If the UE is configured with E-TFCI table (see [7]) and 2ms TTI, it shall use the mapping defined in Annex 
B.l 

If the UE is configured with E-TFCI table 1 (see [7]) and 2ms TTI, it shall use the mapping defined in Annex 
B.2 

If the UE is configured with E-TFCI table (see [7]) and 10ms TTI, it shall use the mapping defined in Annex 
B.3 

If the UE is configured with E-TFCI table 1 (see [7]) and 10ms TTI, it shall use the mapping defined in Annex 
B.4 

The mapping in Transport block size table for 2ms TTI (see table in Annex B.l) can also be obtained using the 
formula below. 

Let k be the chosen E-TFCI, then the corresponding E-DCH transport block size Lj. is given by the following formula 
(informative): 
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Lo=18 

if A: = 0..126 

where 



1 

Ai 1 aoa\ 



p = 



11484 
120^ 



127-1 



The mapping in Transport block size table for 10ms TTI (see table in Annex B.3) can also be obtained using the 
formula below. 

Let k be the chosen E-TFCI, then the corresponding E-DCH transport block size Lj. is given by the following formula 
(informative): 



Lo=18 



if A: = 0..126 

L,,, = [l20*(p)'\ 

where 

1 



P 



^ 20000 ^ 
120 



127-1 



10 Handling of unknown, unforeseen and erroneous 
protocol data 

The list of error cases is reported below: 

a) Use of reserved coding in the MAC header 

If the MAC entity receives a MAC PDU with a header field using a value marked as reserved for this version of 
the protocol, it shall discard the PDU, unless explicitly mentioned otherwise. 

b) Inconsistent MAC header 

If the MAC entity receives a MAC PDU with a header inconsistent with the configuration received from RRC, it 
shall discard the PDU. E.g.: In case DTCH is mapped to RACH/FACH, the MAC entity shall discard a PDU 
with a C/T field indicating a logical channel number that is not configured. 

c) Erroneous MAC header fields 

The MAC PDU shall be discarded if the lower layer gives an error indication for a MAC PDU and a MAC 
header is included in the MAC PDU. 

d) Inconsistent information received on MAC control channels 

If the MAC entity receives inconsistent information on the E-AGCH, it shall ignore the entire message. The 
following conditions constitute inconsistent information: 

The Absolute Grant Scope is "Per HARQ process" and the E-DCH TTI is configured to 10ms. 

- The Identity Type is "Secondary" and the Absolute Grant Value is "INACTIVE". 

The Identity Type is "Secondary" and the Absolute Grant Scope is "Per HARQ process" in this version of the 
protocol. 
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- The Identity type is "Primary", the Absolute Grant value is "INACTIVE", the Absolute Grant Scope is "All 
HARQ processes", the E-DCH TTI is configured to 10ms and a secondary E-RNTI was not configured. 



1 1 Specific functions 

11.1 Traffic volume measurement for dynamic radio bearer 
control 

Dynamic radio bearer control is performed by RRC, based on the traffic volume measurements reported by MAC. 
Traffic volume information is measured in MAC layer and the results are reported from MAC layer to RRC layer. 

At least every TTI, the MAC layer shall receive from each RLC entity the value of its Buffer Occupancy (BO), 
expressed in bytes. RRC can configure MAC to keep track of statistics (i.e. raw BO, average of BO and variance of BO) 
on the BO (see [7]) values of all Radio Bearers mapped onto a given transport channel. When the average or variance 
are requested, an averaging interval duration will also be provided. 

Every time the BO values are reported to MAC, the UE shall verify whether an event was triggered or if a periodic 
report is required (see [7]). If reporting is required (multiple reports may be triggered in a single TTI), the MAC shall 
deliver to RRC the reporting quantities required for the corresponding RBs. In the case of average and variance of BO, 
the averaging should be performed for the interval with the configured duration ending at the time when the event was 
triggered. 

RRC requests MAC measurement report with the primitive CMAC-Measure-REQ including following parameters. 

Measurement information elements. 

Reporting Quantity identifiers 

Indicates what should be reported to RRC layer 

For each RB, BO (optional). Average of BO (optional), or Variance of BO(optional) 

Time interval to take an average or a variance (applicable when Average or Variance is Reporting Quantity) 

Indicates time interval to take an average or a variance of BO 

The calculation of average and variance of BO shall be based on one sample of BO per 10ms during the time 

interval given in this information element. All samples taken in the time interval shall have equal weight in the 

calculation. 

MAC receives RLC PDUs with the primitive MAC-Data-REQ including following parameters. 

- Buffer Occupancy (BO) 

The parameter Buffer Occupancy (BO) indicates for each logical channel the amount of data in number of bytes 
that is available for transmission and retransmission in RLC layer. When MAC is connected to an AM RLC 
entity, control PDUs to be transmitted and RLC PDUs outside the RLC Tx window shall also be included in the 
BO. RLC PDUs that have been transmitted but not negatively acknowledged by the peer entity shall not be 
included in the BO. 

1 1 .2 Control of RACH transmissions 

The MAC sublayer is in charge of controlling the timing of RACH transmissions on transmission time interval level 
(the timing on access slot level is controlled by LI). Note that retransmissions in case of erroneously received RACH 
message part are under control of higher layers, i.e. RLC, or RRC for CCCH (and SHCCH for TDD). 

11 .2.1 Access Service Class selection 

The physical RACH resources (i.e. access slots and preamble signatures for FDD, timeslot and channelisation code for 
3.84 Mcps TDD, SYNCl code for 1.28 Mcps TDD) may be divided between different Access Service Classes in order 
to provide different priorities of RACH usage. It is possible for more than one ASC or for all ASCs to be assigned to the 
same access slot/signature space or SYNCl code. 
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Access Service Classes are numbered in the range < / < NumASC < 7 (i.e. the maximum number of ASCs is 8). An 
ASC is defined by an identifier / that defines a certain partition of the PRACH resources and an associated persistence 
value Pj. A set of ASC parameters consists of NumASC+1 such parameters (/, f ,), / = 0, ..., NumASC. The PRACH 
partitions and the persistence values P, are derived by the RRC protocol from system information (see [7]). The set of 
ASC parameters is provided to MAC with the CMAC-Config-REQ primitive. The ASC enumeration is such that it 
corresponds to the order of priority (ASC = highest priority, ASC 7 = lowest priority). ASC shall be used in case of 
Emergency Call or for reasons with equivalent priority. 

At radio bearer setup/reconfiguration each involved logical channel is assigned a MAC Logical channel Priority (MLP) 
in the range 1,. . .,8. When the MAC sublayer is configured for RACH transmission in the UE, these MLP levels shall be 
employed for ASC selection on MAC. 

The following ASC selection scheme shall be applied, where NumASC is the highest available ASC number and 
MinMLP the highest logical channel priority assigned to one logical channel: 

- in case all TBs in the TB set have the same MLP, select ASC = min(NumASC, MLP); 

in case TBs in a TB set have different priority, determine the highest priority level MinMLP and select 
ASC = min(NumASC, MinMLP). 

When an RRC CONNECTION REQUEST message is sent RRC determines ASC by means of the access class [7]. The 
ASC to be used in these circumstances is signalled to MAC by means of the CMAC-CONFIG-REQ message. 

If MAC has knowledge of a U-RNTI then the ASC is determined in the MAC entity. If no U-RNTI has been indicated 
to MAC then MAC will use the ASC indicated in the CMAC-CONFIG-REQ primitive. 

1 1 .2.2 Control of RACH transmissions for FDD mode 

The RACH transmissions are controlled by the UE MAC sublayer as outlined in figure 1 1 .2.2. 1 . 

NOTE: The figure shall illustrate the operation of the transmission control procedure as specified below. It shall 
not impose restrictions on implementation. MAC controls the timing of each initial preamble ramping 
cycle as well as successive preamble ramping cycles in case that none or a negative acknowledgement is 
received on AICH. 

NOTE: In Cell-FACH state, the UE should co-ordinate the UL transmission schedule with the measurement 

schedule in EACH measurement occasions so as to minimise any delays associated with inter-frequency 
measurements. 

MAC receives the following RACH transmission control parameters from RRC with the CMAC-CONFIG-Req 

primitive: 

a set of Access Service Class (ASC) parameters, which includes for each ASC, i=0,. .., NumASC an 
identification of a PRACH partition and a persistence value P, (transmission probability); 

maximum number of preamble ramping cycles M^.^^; 

range of backoff interval for timer Tboi. given in terms of numbers of transmission 10 ms time intervals Nsoimax 
and NBoimin, applicable when negative acknowledgement on AICH is received. 

When there is data to be transmitted, MAC selects the ASC from the available set of ASCs, which consists of an 
identifier / of a certain PRACH partition and an associated persistence value P,. The procedure to be applied for ASC 
selection is described in subclause H .2. L 

Based on the persistence value P„ the UE decides whether to start the LI PRACH transmission procedure (see [13]) in 
the present transmission time interval or not. If transmission is allowed, the PRACH transmission procedure (starting 
with a preamble power ramping cycle) is initiated by sending of a PHY-ACCESS-REQ primitive. MAC then waits for 
access information from LI via PHY-ACCESS-CNF primitive. If transmission is not allowed, a new persistency check 
is performed in the next transmission time interval. The persistency check is repeated until transmission is permitted. 

When the preamble has been acknowledged on AICH, LI access information with parameter value "ready for data 
transmission" is indicated to MAC with PHY-ACCESS-CNF primitive. Then data transmission is requested with PHY- 
DATA-REQ primitive, and the PRACH transmission procedure shall be completed with transmission of the PRACH 
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message part according to LI specifications. Successfiil completion (TX status) of the MAC transmission control 
procedure shall be indicated to higher layer. 

When PHY indicates that no acknowledgement on AICH is received while the maximum number of preamble 
retransmissions is reached (defined by parameter Preamble_Retrans_Max on LI), a new persistency test is performed in 
the next transmission time interval. The timer T2 ensures that two successive persistency tests are separated by at least 
one 10 ms time interval. 

In case that a negative acknowledgement has been received on AICH a backoff timer Tboi is started. After expiry of the 
timer, persistence check is performed again. Backoff timer Tboi is set to an integer number Nboi of 10 ms time 
intervals, randomly drawn within an interval < NBoimin ^ Nboi ^ NBoimax (with uniform distribution). NBoimin and 
NBoimax may be set equal when a fixed delay is desired, and even to zero when no delay other than the one due to 
persistency is desired. 

Before a persistency test is performed it shall be checked whether any new RACH transmission control parameters have 
been received from RRC with CMAC-CONFIG-Req primitive. The latest set of RACH transmission control parameters 
shall be applied. 

If the maximum number of preamble ramping cycles M^.^,^ is exceeded, failure of RACH transmission shall be reported 
to higher layer. 

Both, transmission failure and successful completion of the MAC transmission control procedure, shall be indicated 
individually for each logical channel of which data was included in the transport block set of that access attempt. When 
transparent mode RLC is employed (i.e. for CCCH), transmission status is reported to RRC with CMAC-STATUS-Ind 
primitive. For logical channels employing acknowledged or unacknowledged mode RLC, transmission status is reported 
to RLC with MAC-STATUS-Ind primitive. 
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Figure 11.2.2.1: RACH transmission control procedure (UE side, informative) 
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1 1 .2.3 Control of RACH transmissions for TDD 

1 1 .2.3.1 Control of RACH transmissions for 3.84 Mcps TDD 

The RACH transmissions are performed by the UE as shown in figure 1 1.2.3.2. 

NOTE: The figure shall illustrate the operation of the transmission control procedure as specified below. It shall 
not impose restrictions on implementation. 

MAC receives the following RACH transmission control parameters from RRC with the CMAC-Config-REQ 
primitive: 

a set of Access Service Class (ASC) parameters, which includes for each ASC, i=0,. . .,NumASC an 
identification of a PRACH partition and a persistence value P, (transmission probability). 

When there is data to be transmitted, MAC selects the ASC from the available set of ASCs, which consists of an 
identifier / of a certain PRACH partition and an associated persistence value P,. The procedure to be applied for ASC 
selection is described in subclause 11.2.1. 

In order to separate different ASCs each PRACH has N sub-channels associated with it (numbered from to N-1). N 
may be assigned the value 1,2,4, or 8 by higher layer signalling. Sub-channel i for a PRACH defined in timeslot k is 
defined as the k:th slot in the frames where SEN mod N = i. Therefore follows the definition: 

Sub-channel i associated to a PRACH defined in timeslot k is defined as the k:th timeslot in the frames where 

SEN mod N = i. 

Eigure 1 1.2.3.1 illustrates the eight possible subchannels for the case, N=8. Eor illustration, the figure assumes that the 
PRACH is assigned timeslot 3. 
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Figure 1 1 .2.3.1 Eight sub-channels for timeslot 3 

Based on the persistence value P, the UE decides whether to send the message on the RACH. If transmission is not 
allowed, a new persistency check is performed in the next transmission time interval. The persistency check is repeated 
until transmission is permitted. If transmission is allowed, a subchannel is randomly selected from the set of available 
subchannels for this ASC. The random subchannel selection shall be such that each of the allowed selections is chosen 
with equal probability. If an available subchannel is not found, the persistency check and subchannel assignment is 
repeated for the next subchannel period. If an available subchannel is found the PRACH transmission procedure is 
initiated by sending of a PHY-Data-REQ primitive. 
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Successful completion (TX status) of the MAC transmission control procedure shall be indicated to higher layer 
individually for each logical channel of which data was included in the transport block set of that access attempt. When 
transparent mode RLC is employed (i.e. for CCCH), transmission status is reported to RRC with CMAC-STATUS-Ind 
primitive. For logical channels employing acknowledged or unacknowledged mode RLC, transmission status is reported 
to RLC with MAC-STATUS-Ind primitive. 
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Figure 11.2.3.2: RACH transmission control procedure for TDD (UE side, informative) 

1 1 .2.3.2 Control of RACH Transmissions for 1 .28 Mcps TDD 

The RACH transmissions are performed by the UE as shown in figure 11. 2. 3. 3 

NOTE: The figure shall illustrate the operation of the transmission control procedure as specified below. It shall 
not impose restrictions on implementation. 

UE MAC receives the following RACH transmission control parameters from RRC with the CMAC-Config-REQ 
primitive: 
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a set of Access Service Class (ASC) parameters, which includes for each ASC, i=0,. . .,NumASC an 
identification of a PRACH partition and a persistence value P, (transmission probability), 

maximum number of synchronisation attempts Mmax. 

When there is data to be transmitted, MAC selects the ASC from the available set of ASCs, which consists of an 
identifier / of a certain PRACH partition and an associated persistence value P,. 

Based on the persistence value Pj, MAC decides whether to start the LI PRACH procedure in the present transmission 
time interval or not. If transmission is allowed, the PRACH transmission procedure (starting with the 
SYNC_UL/FPACH power ramping sequence) is initiated by the sending of a PHY-ACCESS-REQ primitive. MAC 
then waits for access information from LI via the PHY-ACCESS-CNF primitive. If transmission is not allowed, a new 
persistency check is performed in the next transmission time interval. The persistency check is repeated until 
transmission is permitted. 

If a synchronisation burst has been acknowledged on its associated FPACH, PHY will inform MAC by a PHY- 
ACCESS-CNF primitive indicating "ready for RACH data transmission". Then MAC requests data transmission with a 
PHY-DATA-REQ primitive, and the PRACH transmission procedure will be completed with transmission on the 
PRACH resources associated with the FPACH. 

Successful completion of the MAC procedure is indicated to higher layer individually for each logical channel of which 
data was included in the transport block set of that access attempt. When transparent mode RLC is employed (i.e. for 
CCCH), transmission status is reported to RRC with CMAC-STATUS-Ind primitive. For logical channels employing 
acknowledged or unacknowledged mode RLC, transmission status is reported to RLC with MAC-STATUS-Ind 
primitive. 

If no synchronisation burst received an acknowledgement on the FPACH within the maximum number of transmissions 
permitted in a power ramping cycle, PHY will inform MAC by a PHY-ACCESS-CNF primitive indicating "no 
response received on FPACH". If the maximum number of synchronisation attempts permitted, Mmax, has not been 
exceeded, then MAC commences a new persistency test sequence in the next transmission time interval and the PHY- 
ACCESS-REQ procedure is repeated. The timer T2 ensures that two successive persistency tests are separated by at 
least one transmission time interval. If the maximum number of synchronisation attempts is exceeded then MAC 
abandons the RACH procedure. Failure to complete the MAC procedure is indicated to higher layer by the CMAC- 
STATUS-Ind or MAC-STATUS-Ind primitives. 
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Figure 11.2.3.3: RACH transmission control procedure for 1.28 IVIcpsTDD 

(UE side, informative) 



1 1 .3 Void 



1 1 .4 Transport format combination selection in UE (non E-DCH) 

RRC can control the scheduling of uplink data by giving each logical channel a priority between 1 and 8, where 1 is the 
highest priority and 8 the lowest. TFC selection in the UE shall be done in accordance with the priorities indicated by 
RRC. Logical channels have absolute priority, i.e. the UE shall maximise the transmission of higher priority data. 

If the uplink TECS or TEC Subset configured by UTRAN follows the guidelines described in [7] the UE shall perform 
the TEC selection according to the rules specified below. If these guidelines are not followed then the UE behaviour is 
not specified. 

A given TEC can be in any of the following states: 

Supported state; 
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Excess-power state; 

- Blocked state. 

TDD mode UEs in CELL_FACH state using the USCH transport channel and UEs in CELL_DCH state using a DCH 
shall continuously monitor the state of each TEC based on its required transmit power versus the maximum UE transmit 
power (see [7]). The state transition criteria and the associated requirements are described in [12, 14]. The UE shall 
consider that the Blocking criterion is never met for TFCs included in the minimum set of TECs (see [7]). 

The following diagram illustrates the state transitions for the state of a given TEC: 

Eliimnation crk^^^^^ is met Blocking criterion is met 



Recovery criterion is met 

Figure 1 1 .4.1 : State transitions for the state of a given TFC 

FDD Mode UEs in CELL_EACH state may estimate the channel path loss and set to excess power state all the TECs 
requiring more power than the Maximum UE transmitter power (see [7]). All other TECs shall be set to Supported state. 

Every time the set of supported TECs changes, the available bitrate shall be indicated to upper layers for each logical 
channel in order to facilitate the adaptation of codec data rates when codecs supporting variable-rate operation are used. 
The details of the computation of the available bitrate and the interaction with the application layer are not further 
specified. 

Before selecting a TEC, i.e. at every boundary of the shortest TTI, or prior to each transmission on PRACH the set of 
valid TECs shall be established. All TECs in the set of valid TECs shall: 

1. belong to the TECS. 

la. not be restricted by higher layer signalling (e.g. TEC Control, see [7]). 

2. not be in the Blocked state. 

3. be compatible with the RLC configuration. 

4. not require RLC to produce padding PDUs (see [6] for definition). 

5. not carry more bits than can be transmitted in a TTI (e.g. when compressed mode by higher layer scheduling is 
used and the presence of compressed frames reduces the number of bits that can be transmitted in a TTI using 
the Minimum SE configured). 

The UE may remove from the set of valid TECs, TECs in Excess-power state in order to maintain the quality of service 
for sensitive applications (e.g. speech). However, this shall not apply to TECs included in the minimum set of TECs (see 
[7]). Additionally, if compressed frames are present within the longest configured TTI to which the next transmission 
belongs, the UE may remove TECs from the set of valid TECs in order to account for the higher power requirements. 

The chosen TEC shall be selected from within the set of valid TECs and shall satisfy the following criteria in the order 
in which they are listed below: 

1 . No other TEC shall allow the transmission of more highest priority data than the chosen TEC. 
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2. No other TFC shall allow the transmission of more data from the next lower priority logical channels. Apply this 
criterion recursively for the remaining priority levels. 

3. No other TFC shall have a lower bit rate than the chosen TFC. 

In FDD mode the above rules for TFC selection in the UE shall apply to DCH, and the same rules shall apply for TF 
selection on RACH. 

In 3.84 Mcps TDD mode the above rules for TFC selection in the UE shall apply to DCH and USCH. 



11.5 Ciphering 



The ciphering function is performed in MAC (i.e. only in MAC-d) if a radio bearer is using the transparent RLC mode. 
The part of the MAC PDU that is ciphered is the MAC SDU and this is shown in Figure 1 1 .5. 1 below. 

MAC header MAC SDU 



< 


P-M 




► 


TCTF 


UE-ld 
type 


UE-ld 


C/T 


MAC SDU 



Ciphering Unit 

Figure 1 1 .5.1 : Ciphered part unit for a IVIAC PDU 

In case a TTI contains multiple MAC PDUs for a given Transparent mode RB, the ciphering unit for this RB is the 
bitstring concatenation of all the MAC SDUs, resulting in the PLAINTEXT BLOCK, as defined in [15]. In case there is 
only one MAC PDU for a given Transparent mode RB, the ciphering unit is the MAC SDU, resulting in the 
PLAINTEXT BLOCK. The concatenation order is the same as the order of transmission of the Transport Blocks 
between MAC and Physical layer. 

The KEYSTREAM BLOCK as defined in [10] is applied to the PLAINTEXT BLOCK, and the end result, 
CIPHERTEXT BLOCK, becomes the ciphered part for the MAC PDU, in case there is only one MAC PDU per RB. In 
case there is more than one MAC PDU per RB, the CIPHERTEXT BLOCK is split into the corresponding ciphered 
parts for each MAC PDU. The split order is the same as the order of transmission of the Transport Blocks between 
MAC and Physical layer. 

The ciphering algorithm and key to be used are configured by upper layers [7] and the ciphering method shall be 
applied as specified in [10]. 

The parameters that are required by MAC for ciphering are defined in [10] and are input to the ciphering algorithm. The 
parameters required by MAC which are provided by upper layers [7] are listed below: 

MAC-d HFN (Hyper frame number for radio bearers that are mapped onto transparent mode RLC) 

BEARER defined as the radio bearer identifier in [10]. It will use the value RB identity -1 as in [7]) 

- CK (Ciphering Key) 

If the TTI consists of more than one 10 ms radio frame, the CFN of the first radio frame in the TTI shall be used as 
input to the ciphering algorithm for all the data in the TTI. 



1 1 .6 Control of HS-DSCH transmission and reception 



11 .6.1 Network operation 



The following are the functions of the various functional entities at the network in support of the HARQ protocol used 
on HS-DSCH. 
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11.6.1.1 Scheduler 

The scheduler performs the following functions: 

Schedules all UEs within a cell; 

Services priority queues: 

The scheduler schedules MAC-hs SDUs based on information from upper layers. One UE may be associated 
with one or more MAC-d flows. Each MAC-d flow contains HS-DSCH MAC-d PDUs for one or more 
priority queues. 

Determines the HARQ Entity and the queue to be serviced; 

Sets the TSN for new data blocks being transferred from the selected queue; 

- set the TSN to value for the first MAC-hs PDU transmitted for each Queue ID within an HS-DSCH; 

increment the TSN with one for each transmitted MAC-hs PDU on each Queue ID within an HS-DSCH. 

NOTE: The scheduler may re-use TSNs by toggling the NDI bit in order to resume pre-empted transmissions or 
to force the UE to flush the soft buffer. In this case the content of the payload may be changed but care 
should be taken to preserve the higher layer data order. 

- Indicates the Queue ID and TSN to the HARQ entity for each MAC-hs PDU to be transmitted; 

Schedules new transmissions and retransmissions: 

Based on the status reports from HARQ Processes the scheduler determines if either a new transmission or a 
retransmission should be made. A new transmission can however be initiated on a HARQ process at any 
time. Based on a delay attribute provided by upper layers, the scheduler may decide to discard any 'out-of- 
date' MAC-hs SDU. 

Determines the redundancy version: 

The scheduler determines a suitable redundancy version for each transmitted and retransmitted MAC-hs PDU 
and indicates the redundancy version to lower layer. 

- Determines the TDD HCSN; 

Increment UE specific HCSN for each HS-SCCH transmission. 

11.6.1.2 HARQ entity 

- There is one HARQ entity per UE in UTRAN. 

- The HARQ entity sets the Queue ID in transmitted MAC-hs PDUs to the value indicated by the UTRAN 
scheduler. 



The HARQ entity sets the transmission sequence number (TSN) in transmitted MAC-hs PDUs to the value 
indicated by the UTRAN scheduler. 



- The HARQ entity sets the HARQ process identifier in transmitted MAC-hs PDUs. UTRAN should: 

determine a suitable HARQ process to service the MAC-hs PDU and set the HARQ process identifier 
accordingly. 

11.6.1.3 HARQ process 

The HARQ process sets the New data indicator in transmitted MAC-hs PDUs. UTRAN should: 

set the New Data Indicator to the value "0" for the first MAC-hs PDU transmitted by a HARQ process; 



£75/ 



3GPP TS 25.321 version 6.10.0 Release 6 67 ETSI TS 125 321 V6.10.0 (2006-09) 

not increment the New Data Indicator for retransmissions of a MAC-hs PDU; 
increment the New Data Indicator with one for each transmitted MAC-hs PDU containing new data. 
The HARQ process processes received status messages. UTRAN should: 
deliver received status messages to the scheduler. 

11.6.2 UE operation 

The UE operation in support of the HARQ protocol used on HS-DSCH is split among the following four functional 
units with their associated functions. 

11.6.2.1 HARQ Entity 

There is one HARQ entity at the UE which processes the HARQ process identifiers received on the HS-SCCH 
transmissions associated with MAC-hs PDUs received on the HS-DSCH. 

A number of parallel HARQ processes are used in the UE to support the HARQ entity. The number of HARQ processes 
is configured by upper layers: 

Each received MAC-hs PDU shall be allocated to the HARQ process indicated by the HARQ process identifier 
of the MAC-hs PDU. 

11.6.2.2 HARQ process 

The HARQ process processes the New Data Indicator indicated by lower layers for each received MAC-hs PDU. 

The UE may: 

for FDD, if the MAC-hs PDU is received within 5 sub-frames from the reception of the previous MAC-hs PDU 
intended for this HARQ process; or 

for TDD, if the MAC-hs PDU is received before generation of feedback resulting from reception of a previous 
MAC-hs PDU for the same H-ARQ process: 

- discard the MAC-hs PDU. 

The UE shall: 

if the New Data Indicator has been incremented compared to the value in the previous received transmission in 
this HARQ process or this is the first received transmission in the HARQ process: 

replace the data currently in the soft buffer for this HARQ process with the received data. 

if the Transport Block Size index value is equal to 111111 (FDD only): 

generate a positive acknowledgement (ACK) of the data in this HARQ process; 

discard the received data; 

assume that the data has been successfully decoded. 

if the New Data Indicator is identical to the value used in the previous received transmission in the HARQ 
process: 

if the Transport Block Size index value is equal to 111111 (FDD only): 

assume that the transport block size is identical to the last valid transport block size signalled for this 
HARQ process. 

if the data has not yet been successfully decoded: 

combine the received data with the data currently in the soft buffer for this HARQ process. 
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if the transport block size is different from the last valid transport block size signalled for this HARQ 
process: 

the UE may replace the data currently in the soft buffer for this HARQ process with the received data. 

if the data in the soft buffer has been successfully decoded and no error was detected: 

deliver the decoded MAC-hs PDU to the reordering entity; 

generate a positive acknowledgement (ACK) of the data in this HARQ process, 
else: 

generate a negative acknowledgement (NAK) of the data in this HARQ process; 

schedule the generated positive or negative acknowledgement for transmission and the time of transmission 
relative to the reception of data in a HARQ process is configured by upper layer. 

The HARQ process processes the Queue ID in the received MAC-hs PDUs. The UE shall: 

arrange the received MAC-hs PDUs in queues based on the Queue ID. 

11.6.2.3 Reordering entity 
11.6.2.3.1 Definitions 

In the functions described in this section the following definitions apply: 
Parameters 

- Transmitter window size (TRANSMIT_WINDOW_SIZE) 

TRANSMIT_WINDOW_SIZE is the size of the transmitter window according to the definition below. This is a 
parameter in the Node B and the value of the parameter is configured by higher layers. 

- Receiver window size (RECEIVE_WINDOW_SIZE) 

RECEIVE_WINDOW_SIZE is the size of the receiver window according to the definition below. This is a 
parameter in the UE and the value of the parameter is configured by higher layers. 

State variables 

All state variables are non-negative integers. MAC-hs PDUs are numbered by modulo integer Transmission sequence 
numbers (TSN) cycling through the field to 63. All arithmetic operations contained in the present document on 
next_expected_TSN, RcvWindow_UpperEdge, T1_TSN and TSN_flush are affected by the 64 modulus. When 
performing arithmetic comparisons of state variables or Transmission sequence number values a 64 modulus base shall 
be used. This modulus base is subtracted (within the appropriate field) from all the values involved and then an absolute 
comparison is performed. RcvWindow_UpperEdge - RECEIVE_WINDOW_SIZE + 1 shall be assumed to be the 
modulus base. 

next_expected_TSN: 

The next_expected_TSN is the Transmission sequence number (TSN) following the TSN of the last in-sequence 
MAC-hs PDU received. It shall be updated according to the procedures given in subclauses 1 1.6.2.3.2, 1 1.6.2.5 
and 11.6.2.6. The initial value of next_expected_TSN =0. 

Re vWindo w_UpperEdge : 

The RcvWindow_UpperEdge represents the TSN, which is at the upper edge of the receiver window. After the 
first MAC-hs PDU has been received successfully, it also corresponds to the MAC-hs PDU with the highest 
TSN of all received MAC-hs PDUs. The initial RcvWindow_UpperEdge equals 63. RcvWindow_UpperEdge is 
updated based on the reception of new MAC-hs PDU according to the procedure given below. 

- T1_TSN: 

The TSN of the latest MAC-hs PDU that cannot be delivered to the disassembly entity, when the timer Tl is 
started. 
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Timers 



Re-ordering release timer (Tl): 

The Re-ordering release timer Tl controls the stall avoidance in the UE reordering buffer as described below. 

The value of Tl is configured by upper layers. 



Other definitions 

Receiver window: 

The receiver window defines TSNs of those MAC-hs PDUs that can be received in the receiver without causing 
an advancement of the receiver window according to the procedure below. The size of the receiver window 
equals RECEIVE_WINDOW_SIZE and spans TSNs going from RcvWindow_UpperEdge - 
RECEIVE_WINDOW_SIZE + 1 to RcvWindow_UpperEdge included. 

1 1 .6.2.3.2 Reordering functionality 

If no timer Tl is active: 

the timer Tl shall be started when a MAC-hs PDU with TSN > next_expected_TSN is correctly received. 
- T1_TSN shall be set to the TSN of this MAC-hs PDU. 
If a timer Tl is already active: 

no additional timer shall be started, i.e. only one timer Tl may be active at a given time. 
The timer Tl shall be stopped if: 

the MAC-hs PDU with TSN = T1_TSN can be delivered to the disassembly entity before the timer expires. 

When the timer Tlexpires and T1_TSN > next_expected_TSN: 

all correctly received MAC-hs PDUs with TSN > next_expected_TSN up to and including T1_TSN-1 shall be 
delivered to the disassembly entity; 

all correctly received MAC-hs PDUs up to the next not received MAC-hs PDU shall be delivered to the 
disassembly entity. 

next_expected_TSN shall be set to the TSN of the next not received MAC-hs PDU. 

When the timer Tl is stopped or expires, and there still exist some received MAC-hs PDUs that can not be delivered to 
higher layer: 

timer Tl is started 

set T1_TSN to the highest TSN among those of the MAC-hs PDUs that can not be delivered. 

Transmitter operation: 

After the transmitter has transmitted a MAC-hs PDU with TSN=SN, any MAC-hs PDU with TSN < SN - 
TRANS MIT_WINDOW_SIZE should not be retransmitted to avoid sequence number ambiguity in the receiver. 

Receiver operation: 

When a MAC-hs PDU with TSN = SN is received: 

if SN is within the receiver window: 

if SN < next_expected_TSN, or this MAC-hs PDU has previously been received: 
- the MAC-hs PDU shall be discarded; 
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else: 

- the MAC-hs PDU shall be placed in the reordering buffer at the place indicated by the TSN. 

if SN is outside the receiver window: 

the received MAC-hs PDU shall be placed above the highest received TSN in the reordering buffer, at the 
position indicated by SN; 

RcvWindow_UpperEdge shall be set to SN thus advancing the receiver window; 

- any MAC-hs PDUs with TSN < RcvWindow_UpperEdge - RECEIVE_WINDOW_SIZE, i.e. outside the 
receiver window after its position is updated, shall be removed from the reordering buffer and be delivered to 
the disassembly entity; 

if next_expected_TSN is below the updated receiver window: 

- next_expected_TSN shall be set to RcvWindow_UpperEdge - RECEIVE_WINDOW_SIZE + 1 ; 

if the MAC-hs PDU with TSN = next_expected_TSN is stored in the reordering buffer: 

all received MAC-hs PDUs with consecutive TSNs from next_expected_TSN (included) up to the first not 
received MAC-hs PDU shall be delivered to the disassembly entity; 

next_expected_TSN shall be advanced to the TSN of this first not received MAC-hs PDU. 

In case a UE has insufficient memory to process a received MAC-hs PDU, it shall perform the following set of 
operations: 

select TSN_flush such that: next_expected_TSN < TSN_flush < RcvWindow_UpperEdge + 1 ; 

deliver all correctly received MAC-hs PDUs with TSN < TSN_flush to the disassembly entity; 

- if the MAC-hs PDU with TSN=TSN_flush has previously been received: 

deliver all received MAC-hs PDUs with consecutive TSNs from TSN_flush (included) up to the first not 
received MAC-hs PDU to the disassembly entity; 

advance next_expected_TSN to the TSN of this first not received MAC-hs PDU. 

else: 

set next_expected_TSN to TSN_flush. 

11.6.2.4 Disassembly entity 

For each MAC-hs PDU that is delivered to the disassembly entity, the UE shall: 
remove any padding bits if present; 
remove the MAC-hs header; 

- deliver the MAC-d PDUs in the MAC-hs PDU to MAC-d. 

11.6.2.5 IVIAC-hs Reset 

If a reset of the MAC-hs entity is requested by upper layers, the UE shall at the activation time indicated by higher 
layers: 

flush soft buffer for all configured HARQ processes; 

stop all active re-ordering release timer (Tl) and set all timer Tl to their initial value; 

start TSN with value for the next transmission on every configured HARQ process; 
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initialise the variables RcvWindow_UpperEdge and next_expected_TSN to their initial values; 

- disassemble all MAC-hs PDUs in the re -ordering buffer and deliver all MAC-d PDUs to the MAC-d entity; 
flush the re-ordering buffer. 

and then: 

If the MAC-hs reset was initiated due to reception of the IE "MAC-hs reset indicator" by the upper layers [7]: 
indicate to all AM RLC entities mapped on HS-DSCH to generate a status report. 

1 1 .6.2.6 Reconfiguration of MAC-hs parameters 

The parameters for a MAC-hs entity may be reconfigured (modifed) by upper layers. 
When a parameter is reconfigured by the upper layer, the UE shall: 

start using the reconfigured value of the parameter at the activation time indicated by higher layers. 
If the parameter Tl is reconfigured for an already existing re-ordering queue, the UE shall: 

start to use the new value of Tl the next time Tl is started. 

If the MAC-d PDU size info (i.e. mapping of MAC-d PDU size index to MAC-d PDU size) is reconfigured for an 
already existing re -ordering queue, at the activation time indicated by higher layers, the UE shall: 

stop timer Tl if running; 

set next_expected_TSN to (highest TSN of received MAC-hs PDU of this re -ordering queue + 1); 

deliver all correctly received MAC-hs PDUs in this re-ordering queue to the disassembly entity and use the old 
MAC-d PDU size info for these MAC-hs PDUs. 

If the parameter RECEIVE_WINDOW_SIZE is reconfigured for a re-ordering queue, the UE shall: 

- set RECEIVE_WINDOW_SIZE to the new value; 

remove any MAC-hs PDUs in this re -ordering queue with TSN < RcvWindow_UpperEdge - 
RECEIVE_WINDOW_SIZE (i.e. outside the receiver window after its size is updated) from the reordering 
buffer and deliver these MAC-hs PDUs to the disassembly entity; 

if next_expected_TSN is below the receiver window after its size is updated: 

- set next_expected_TSN to RcvWindow_UpperEdge - RECEIVE. WINDOW_SIZE + 1 ; 

deliver all received MAC-hs PDUs in this re-ordering queue with consecutive TSNs from 
next_expected_TSN (included) up to the first not received MAC-hs PDU to the disassembly entity; 

advance next_expected_TSN to the TSN of this first not received MAC-hs PDU. 

If the "Memory Partitioning" (see [7]) for soft buffer is reconfigured, the UE shall: 

flush soft buffer for all configured HARQ processes. 

1 1 .7 HS-DSCH Provided Bit Rate measurement 

The HS-DSCH Provided Bit Rate measurements is defined as follows: 

for each priority class the MAC-hs entity measures the total number of MAC-d PDU bits whose transmission 
over the radio interface has been considered successful by MAC-hs in Node-B during the last measurement 
period, divided by the duration of the measurement period; 

the values reported by MAC-hs shall be raw samples; 

the measurement period shall be [100 ms]; 
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when the cell portions are defined in a cell, the HS-DSCH Provided Bit Rate shall be measured for each cell 
portion. 

1 1 .8 Control of E-DCH transmission and reception 
11.8.1 UE operation 

11.8.1.1 HARQ Operation 

11.8.1.1.1 HARQ entity 

There is one HARQ entity at the UE. A number of parallel HARQ processes are used in the UE to support the HARQ 
entity, allowing transmissions to take place continuously while waiting for the feedback on the successful or 
unsuccessful reception of previous transmissions. 

At a given TTI, the HARQ entity identifies the HARQ process for which a transmission should take place. Also, based 
on the timing, it routes the receiver feedback (ACK/NACK information), relayed by the physical layer, to the 
appropriate HARQ process. 

The number of HARQ processes is equal to the HARQ round-trip-time (HARQ_RTT). The HARQ_RTT is equal to 4 
for 10ms TTI and 8 for 2ms TTI. The TTI duration shall be configured by the higher layers. Each process is associated 
with a number from to HARQ_RTT-1. 

After each TTI, the HARQ entity shall: 

if the buffer of the HARQ process corresponding to the next TTI is empty: 

notify the E-TFC selection entity that the next TTI is available for a new transmission; 

if the "E-TFC Selection" entity indicates the need for a new transmission: 

obtain the transmission information (i.e. HARQ profile, whether triggered Scheduling Information is 
included and whether it is sent alone) from the "E-TFC Selection" entity; 

- obtain the MAC-e PDU to transmit from the "Multiplexing and TSN setting" entity; 

instruct the HARQ process corresponding to this TTI to trigger the transmission of this new payload 
using the identified HARQ profile parameters. 

else: 

instruct the HARQ process to generate a re-transmission. 

11.8.1.1.2 HARQ process 

Each HARQ process is associated with a physical buffer (HARQ buffer). 

Each HARQ process maintains the state variable CURRENT_TX_NB, which indicates the number of transmissions that 
have taken place for the MAC-e PDU currently in the buffer. When the HARQ process is established, 
CURRENT_TX_NB shall be initialized to 0. 

At the time of a new transmission, the HARQ entity provides the HARQ profile to use for all transmissions and re- 
transmissions of this MAC-e PDU. This HARQ profile includes information on the maximum number of transmissions 
to perform, and the power offset with which to configure the physical layer. 

If the HARQ entity provides a new PDU, the HARQ process shall: 

- set CURRENT_TX_NB to 0; 

- set CURRENT_RSN to 0; 

- store the MAC-e PDU in the associated HARQ buffer; 
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- generate a transmission as described below. 

If the HARQ entity requests a re -transmission, the HARQ process shall: 

generate a transmission as described below. 
To generate a transmission, the HARQ process shall, regardless of any overlapping with a compressed mode gap; 

- instruct the physical layer to set the RSN field on the E-DPCCH to CURRENT_RSN; 

instruct the physical layer to generate a transmission with the power offset corresponding to the HARQ profile 
and the redundancy version corresponding to the RSN value and the transmission timing (i.e. the CFN and in the 
case of 2ms TTI, sub-frame number as described in [16]); 

- ifCURRENT_RSN<3: 

- increment CURRENT_RSN by 1 ; 

- increment CURRENT_TX_NB by 1 ; 
The HARQ process shall: 

if an ACK is received from the RLS containing the serving cell; or 

if an ACK is received from any RLS and the transmission included higher layer data (i.e. not only included 
Scheduling Information); or 

if CURRENT_TX_NB > maximum number of transmissions indicated in the transmission HARQ profile: 

- flush the HARQ buffer; 

if the transmission included Scheduling Information which was triggered per subclause 11 .8. 1 .6 and if no 
ACK for that transmission was received from the RLS containing the serving cell: 

notify the Scheduling Information Reporting function that the HARQ process failed to deliver the 
triggered Scheduling Information to the RLS containing the serving cell (see subclause 11. 8. 1.6. 3). 

NOTE: In the case where the Scheduling Information is transmitted alone, without any higher layer data the UE 
will keep re-transmitting the Scheduling Information until an ACK is received from the RLS containing 
the serving cell or the maximum number of re-transmissions is reached. In the latter case, periodic 
triggering will be relied upon for reliability. 

1 1 .8.1 .2 Multiplexing and TSN setting entity 

There is one Multiplexing and TSN setting entity at the UE. A number of TSN setting processes are used to support 
independent numbering of transmissions from different logical channels. 

11.8.1.2.1 TSN setting process operation 

There is one TSN setting process at the UE for each logical channel. When a MAC-es PDU is transmitted, the UE 
operation in support of the re-ordering functionality consists in generating an explicit sequence number (TSN) for the 
MAC-es PDU intended for the associated re-ordering queue. In one TTI, there is only one TSN per logical channel: one 
for the MAC-es PDU that is transmitted. 

Each TSN setting process maintains the state variable CURRENT_TSN, which indicates the sequence number to be 
included in the header of the following MAC-es PDU to be generated. When the TSN setting process is established, 
CURRENT_TSN shall be initialized to 0. 

When a new payload needs to be generated for the associated re-ordering queue, the Multiplexing and TSN setting 
entity shall: 

- set the TSN of the transmission to CURRENT_TSN; 
After each MAC-es PDU is multiplexed: 

- increment CURRENT_TSN by 1 ; 
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- if CURRENT_TSN > 63: 
- set CURRENT_TSN = 0. 

11 .8.1 .3 Serving Grant Update 

UEs in CELL_DCH state, configured with an E-DCH transport channel shall maintain a Serving Grant and the list of 
active HARQ processes based on the absolute and relative grant commands decoded on the configured E-AGCH and E- 
RGCH(s). 

Each Absolute Grant or Relative Grant command is applied at a specific TTI. This association is implicit based on the 
timing of the E-AGCH and E-RGCH (see [13]). The timing is tight enough that this relationship is un-ambiguous. 

The activation/deactivation of one or all processes is only applicable to processes for which transmission of scheduled 
data is allowed according to RRC signalling 

Process activation of an active process does not result in any action taken by the UE. 

11.8.1.3.1 Baseline Procedure 

The Serving Grant Update procedure shall be applied at every TTI boundary and shall take into account the Absolute 
Grant message, Serving Relative Grant and non-serving Relative Grants that apply to the TTI. 

The UE shall: 

1> set reference_ETPR to the E-DPDCH to DPCCH power ratio as defined in subclause 3.1.2; 

1> if an Absolute Grant was received for this TTI: 

2> if the Identity type is "Primary", and the Absolute Grant value is set to "INACTIVE": 

3> if Absolute Grant Scope indicates "Per HARQ process" and a 2ms TTI is configured: 

4> de-activate the process given by the value of CURRENT_HARQ_PROCESS. 

3> if Absolute Grant Scope indicates "All HARQ processes" and a secondary E-RNTI was configured by 
higher layers: 

4> activate all HARQ processes; 

4> set Serving_Grant = Stored_Secondary_Grant; 

4> set Primary_Grant_Available to "False". 

3> if Absolute Grant Scope indicates "All HARQ processes", a 2ms TTI is configured and a secondary E- 
RNTI was not configured by higher layers: 

4> deactivate all HARQ processes (if a process was inactive it remains inactive, if a process was active it 
becomes inactive). 

2> else if the Absolute Grant Value is different from "INACTIVE": 

3> if the Identity Type is "Secondary": 

4> set Stored_Secondary_Grant = Absolute Grant Value. 

3> if the Identity Type is "Primary" or Primary_Grant_Available is set to "False": 

4> set Serving_Grant = Absolute Grant Value. 

4> if the Identity Type is "Primary": 

5> set Primary_Grant_Available to "True"; 

5> if Absolute Grant Scope indicates "Per HARQ process": 

6> activate the process given by the value of CURRENT_HARQ_PROCESS. 
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5> if Absolute Grant Scope indicates "All HARQ processes": 

6> activate all HARQ processes. 

5> if AG_Timer is not active, it shall be started, otherwise it shall be restarted. 

1> else (no Absolute Grant received): 

2> if the HARQ process given by the value of CURRENT_HARQ_PROCESS is active; and 

2> if Primary_Grant_Available is equal to "True"; and 

2> if Serving_Grant <> "Zero_Grant" ; and 

2> if AG_Timer has expired; and 

2> if there was a scheduled transmission (see Note) in the previous TTI of the HARQ process given by the value 
of CURRENT_HARQ_PROCESS: 

3> if the Serving Relative Grant indicates "UP": 

4> determine the Serving_Grant in accordance with subclause 9.2.5.2.1. 

3> else, if the Serving Relative Grant indicates "DOWN": 

4> determine the Serving_Grant in accordance with subclause 9.2.5.2.1. 

1> if any Non-Serving Relative Grants indicate "DOWN" for this TTI and Serving_Grant <> "Zero_Grant" : 

2> Serving_Grant = MIN(Serving_Grant, Serving_Grant determined in accordance with subclause 9.2.5.2.1); 

2> Maximum_Serving_Grant = Serving_Grant. 

2> if Non_Serving_RG_Timer is not active it shall be started, otherwise it shall be restarted; 

1> else if no Non-Serving Relative Grants indicate "DOWN" for this TTI: 

2> if Non_Serving_RG_Timer has not expired: 

3> Serving_Grant = MIN(Maximum_Serving_Grant, Serving_Grant). 

NOTE: Scheduling Information sent alone is not considered as a scheduled transmission. 

1 1 .8.1 .3.2 Handling at start of E-DCH transmission 

When E-DCH transmission is started (i.e. the RRC variable E_DCH_TRANSMISSION is changed from "false" to 
"true"), the UE shall: 



activate all HARQ processes; 

if the lE's "Serving Grant value" and "Primary/Secondary Grant Selector" are provided by higher layers: 

update the state variables and timers according to subclause 11. 8. 1.3.5. 
else: 

initialise the state variable Serving_Grant to Zero_Grant; 
initialise the state variable Primary_Grant_Available to "False"; 
initialise the state variable Stored_Secondary_Grant to "Zero_Grant" . 
initialise the state variables reference_ETPR to "Minimum_Grant". 



£75/ 



3GPP TS 25.321 version 6.10.0 Release 6 76 ETSI TS 125 321 V6.10.0 (2006-09) 

1 1 .8.1 .3.3 Handling at serving cell change 

At E-DCH serving cell change, the UTRAN may configure the UE with the grant value to use in the new cell and shall 
indicate whether the UE should monitor Absolute Grant Messages with the secondary E-RNTI. 

The UE shall: 

activate all HARQ processes; 

if the lE's "Serving Grant value" and "Primary/Secondary Grant Selector" are provided by higher layers: 

update the state variables and timers according to subclause 1 1.8.1.3.5. 

- else: 

continue to use the current values of state variables Serving_Grant and Primary_Grant_ Available; 
initialise the state variable Stored_Secondary_Grant to "Zero_Grant" . 

11.8.1.3.4 Handling at TTI change 

At E-DCH TTI change, the UE shall: 
activate all HARQ processes; 

initialise the state variables reference_ETPR to "Minimum_Grant"; 
reset Non_Serving_RG_Timer and AG_Timer; 

if the lE's "Serving Grant value" and "Primary/Secondary Grant Selector" are provided by higher layers: 
update the state variables and timers according to subclause 11. 8. 1.3.5. 

- else: 

continue to use the current values of state variables Serving_Grant and Primary_Grant_Available; 
initialise the state variable Stored_Secondary_Grant to "Zero_Grant" . 

11.8.1.3.5 Higher Layer Signalling 

When the lE's "Serving Grant value" and "Primary/Secondary Grant Selector" are provided by higher layers: 

set the state variable Serving_Grant to the value of the lE's "Serving Grant value" provided by higher layers; 
if the lE's "Primary/Secondary Grant Selector" is provided by higher layers as "Primary": 

if AG_Timer is not active, it shall be started, otherwise it shall be restarted; 

set the state variable Primary_Grant_Available to "True"; 

set the state variable Stored_Secondary_Grant to "Zero_Grant" . 
if the lE's "Primary/Secondary Grant Selector" is provided by higher layers as "Secondary": 

set the state variable Primary_Grant_Available to "False"; 

set the state variable Stored_Secondary_Grant to the value of the lE's "Serving Grant value" provided by 
higher layers. 

11.8.1.4 E-TFC Selection 

In FDD mode, the rules for E-TFC selection provided below shall apply to UEs in CELL_DCH state with an E-DCH 
transport channel configured. These UEs shall apply the E-TFC selection procedure when invoked by the HARQ entity 
(see subclause 11.8.1.1.1). In the case where a 2ms TTI is configured, E-TFC selection shall not be performed for TTIs 
that overlap with an uplink compressed mode gap. The E-TFC restriction procedure described in [12] shall always be 
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applied before the E-TFC selection process below. Furthermore, for UEs that are also configured with a DCH transport 
channel on uplink, the TFC selection procedure shall be applied before either of these. 

For each MAC-d flow, RRC configures MAC with a HARQ profile and a multiplexing list. Additionally, RRC 
configures MAC with a power offset for "Control-only" transmissions. This power offset and a maximum number of 
HARQ transmissions of 8 will be used to define a HARQ profile for "Control-only" transmissions which will be used, 
in case the Scheduling Information needs to be transmitted without any higher-layer data. The HARQ profile includes 
the power offset and maximum number of HARQ transmissions to use for this MAC-d flow. The multiplexing list 
identifies for each MAC-d flow(s), the other MAC-d flows from which data can be multiplexed in a transmission that 
uses the power offset included in its HARQ profile. 

RRC can control the scheduling of uplink data by giving each logical channel a priority between 1 and 8, where 1 is the 
highest priority and 8 the lowest. E-TFC selection in the UE shall be done in accordance with the priorities indicated by 
RRC. Logical channels have absolute priority, i.e. the UE shall maximise the transmission of higher priority data. 

RRC can allocate non-scheduled transmission grants to individual MAC-d flows in order to reduce the transmission 
delays. When a 2ms TTI is configured each non-scheduled grant is applicable to the specific set of HARQ processes 
indicated by RRC. The applicability of scheduled grants can be also restricted to a specific set of HARQ processes 
when a 2ms TTI is configured. HARQ process restriction and reservation is under the control of the serving cell Node B 
and indicated to the UE by RRC. 

For each configured MAC-d flow, a given E-TFC can be in any of the following states: 

Supported state; 

- Blocked state. 

At each TTI boundary, UEs in CELL_DCH state with an E-DCH transport channel configured shall determine the state 
of each E-TFC for every MAC-d flow configured based on its required transmit power versus the maximum UE 
transmit power (see [7] and [12]). If no DCH transport channel is configured or if a DCH transport channel is 
configured and the selected TFC is "empty" (see [3]), the UE shall consider that E-TFCs included in the minimum set of 
E-TFCs are always in supported state (see [7]). 

At every TTI boundary for which a new transmission is requested by the HARQ entity (see subclause 11.8.1.1.1), the 
UE shall perform the operations described below. UEs configured both with DCH and E-DCH transport channels shall 
perform TFC selection before performing E-TFC selection. 

The Serving Grant Update function provides the E-TFC selection function with the maximum E-DPDCH to DPCCH 
power ratio that the UE is allowed to allocate for the upcoming transmission for scheduled data (held in the Serving 
Grant state variable - see subclause 11.8.1.3). 

The HARQ process ID for the upcoming transmission is determined using the following formulae: 

- For 2ms TTI: CURRENT_HARQ_PROCESS_ID = [5*CFN + subframe number] mod HARQ_RTT 

- For 10ms TTI: CURRENT_HARQ_PROCESS_ID = [CFN] mod HARQ_RTT 

Based on this current HARQ process ID and the RRC configuration, the UE shall determine whether to take the 
scheduled and non-scheduled grants into account in the upcoming transmission. If they are not supposed to be taken 
into account, then the corresponding grant shall be assumed to not exist. If the variable Serving_Grant has the value 
"Zero_Grant" after the Serving Grant Update, then the Serving Grant shall not be taken into account in the upcoming 
transmission. 

When Scheduling Information is triggered per subclause 1 1.8.1.6, the E-TFC selection and data-allocation process shall 
assume that a non-scheduled grant is available for its transmission and that Scheduling Information has a priority higher 
then any other logical channel. Furthermore the HARQ process used for the upcoming transmission shall be assumed to 
be active and not L3 restricted for the transmission of the Scheduling Information, i.e. transmission of Scheduling 
Information can take place on this process. 

The transmission format and data allocation shall follow the requirements below: 

Only E-TFCs from the configured E-TFCS shall be considered for the transmission; 
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For all logical channels, if the logical channel belongs to a non-scheduled MAC-d flow, its data shall be 
considered as available up to the corresponding non-scheduled grant, if the logical channel does not belong to a 
non-scheduled MAC-d flow, its data shall be considered as available up to the Serving Grant; 

The power offset for the transmission is the one from the HARQ profile of the MAC-d flow that allows highest- 
priority data to be transmitted. If more than one MAC-d flow allows data of the same highest priority to be 
transmitted, it is left to implementation to select which MAC-d flow to prefer); 

In case the variable Serving_Grant has the value "Zero_Grant" after the Serving Grant Update function and there 
is no data available for MAC-d flows for which non-scheduled grants were configured and the transmission of 
Scheduling Information has been triggered, the "Control-only" HARQ profile configured by the higher layers 
shall be used. 

The Nominal Power Offset shall be set to the power offset included in the transmission HARQ profile; 

The data allocation shall maximize the transmission of higher priority data; 

The amount of data from MAC-d flows for which non-scheduled grants were configured shall not exceed the 
value of the non-scheduled grant; 

If a 10ms TTI is configured and the TTI for the upcoming transmission overlaps with a compressed mode gap, 
the Serving_Grant provided by the Serving Grant Update function shall be scaled back as follows: 

15 

where SG" represents the modified serving grant considered by the E-TFC selection algorithm and Nc represents 
the number of non DTX slots in the compressed TTI; 

When not in a power limited condition the maximum amount of data from MAC-d flows for which no non- 
scheduled grants were configured shall be quantized to the next smaller supported E-TFC based on amplitude 
ratios prior to the quantization according to subclause 5.1.2.5B.2.3 of [13], the Serving Grant (after adjustment 
for compressed frames), the power offset from the selected HARQ profile, the non-scheduled grants (if any) and 
Scheduling Information (if any); In the case a 2ms TTI is configured and the HARQ process is inactive, the UE 
shall not include any such data in the transmission; 

The Scheduling Information is always sent when triggered (see subclause 1 1.8.1.6); 

Only E-TFCs in supported state shall be considered; 

The E-TFC resulting in the smallest amount of padding for the selected MAC-es PDUs and corresponding 
MAC-e/es headers, shall be selected including the case when the Scheduling Information needs to be 
transmitted. 

Once an appropriate E-TFC and data allocation are found according to the rules above, the "Multiplexing and TSN 
Setting' entity shall generate the corresponding MAC-e PDU. 

The E-TFC selection function shall provide this MAC-e PDU and transmission HARQ profile to the HARQ entity. The 
maximum number of HARQ transmissions and the power offset in this profile, shall be set respectively to the maximum 
of the Max Number of HARQ Transmissions of the HARQ profiles from all the MAC-d flows from which data is 
multiplexed into the transmission and to the Nominal Power Offset. The HARQ entity shall also be informed of whether 
the transmission includes Scheduling Information and whether this information is sent by itself or with higher-layer 
data. The E-TFC selection function shall provide the E-TFCI for the selected E-TFC to the HARQ entity. 

11.8.1.5 Happy Bit Setting 

The Happy Bit is included on the E-DPCCH for every E-DCH transmission. E-DCH transmissions shall not be 
triggered specifically to allow the transmission of the happy bit. 

RRC configures MAC with the duration Happy_Bit_Delay_Condition, over which to evaluate the current grant relative 
to the TEBS after application of the E-TFC selection procedure described in subclause 11 .8. 1 .4. 

For every E-DCH transmission, the Happy Bit shall be set to "unhappy" if the three following criteria are met: 
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1) UE is transmitting as much scheduled data as allowed by the current Serving_Grant in E-TFC selection; and 

2) UE has enough power available to transmit at higher data rate; and 

3) Based on the same power offset as the one selected in E-TFC selection to transmit data in the same TTI as the 
Happy Bit, TEBS would require more than Happy_Bit_Delay_Condition ms to be transmited with the current 
Serving_Grant x the ratio of active processes to the total number of processes. 

The first criteria is always true for a deactivated process and the ratio of the third criteria is always 1 for 10ms TTI. 

Otherwise, the Happy Bit shall be set to "happy". 

In order to assess if it has enough power available to transmit at higher data rate the UE shall: 

1) Identify the E-TFC that has a transport block size at least x bits larger than the transport block size of the E-TFC 
selected for transmission in the same TTI as the Happy Bit, where x is the smallest RLC PDU size configured 
among all the logical channels that do not belong to non-scheduled MAC-d flows and which have data in the 
buffer; and 

2) Based on the same power offset as the one selected in E-TFC selection to transmit data in the same TTI as the 
Happy Bit, check that the identified E-TFC is supported i.e. not blocked. 

1 1 .8.1 .6 Scheduling Information reporting 

Scheduling information reports will be triggered differently depending on the value of the variable Serving_Grant after 
the Serving Grant Update function. The triggering of a report shall be indicated to the E-TFC selection function at the 
first new transmission opportunity (this process may be delayed in case the HARQ processes are occupied with re- 
transmissions). 

Even if multiple events are triggered by the time a new transmission can take place, only a single scheduling 
information header will be included in the payload. 

The Scheduling Information shall not be transmitted if the TEBS is zero, even if it was triggered by one of the 
configured triggering mechanisms. If the Scheduling Information needs to be included in the MAC-e PDU according to 
subclause 9.2.4.2, it shall be transmitted regardless of TEBS status. 

The transmission of Scheduling Information can take place on every HARQ process, even on those processes for which 
transmission is restricted according to RRC or deactivated by absolute grants, i.e. processes on which scheduled and/or 
non-scheduled transmission can not take place. 

The description of the behaviour in the two cases is provided below. 

1 1 .8.1 .6.1 Report Triggering when SG = 'Zero_Grant' or all processes are deactivated 

If the Serving_Grant has the value "Zero_Grant" or all processes are deactivated, and the TEBS becomes larger than 
zero, the transmission of Scheduling Information shall be triggered. 

If data with higher priority than the data already in the transmission buffer arrives, the transmission of a Scheduling 
Information shall be triggered. 

RRC can also configure MAC with periodic Scheduling Information triggering. The periodic trigger timer T_SING 
(Timer Scheduling Information - "Zero_Grant") shall be started once the Serving_Grant variable becomes 
"Zero_Grant" or all processes are deactivated and TEBS is larger than zero. 

When T_SING expires, the transmission of a Scheduling Information shall be triggered. 

T_SING shall be restarted when the transmission of a Scheduling Information is triggered. 

T_SING shall be stopped and reset once the Serving_Grant variable in the Serving Grant Update function takes a value 
other than "Zero_Grant" and at least one process is activated. 
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1 1 .8.1 .6.2 Report Triggering when SG <> 'Zero_Grant' and at least one process is activated 

If an E-DCH serving cell change occurs and if the new E-DCH serving cell was not part of the previous Serving E-DCH 
RLS, the transmission of a Scheduling Information shall be triggered. 

RRC can configure MAC with periodic triggering also for the case when the variable Serving_Grant <> "Zero_Grant" 
and at least one process is activated. The periodic trigger timer T_SIG (Timer Scheduling Information - different from 
"Zero_Grant") can be configured to a different value than T_SING. 

T_SIG shall be started once the Serving_Grant variable becomes <> "Zero_Grant" and at least one process is activated. 

When T_SIG expires, the transmission of a new Scheduling Information shall be triggered. 

T_SIG shall be stopped and reset once the Serving_Grant variable in the Serving Grant Update function becomes equal 
to "Zero_Grant" or all processes are deactivated. 

T_SIG shall be restarted when the transmission of a Scheduling Information is triggered. 

Once the Serving_Grant variable in the Serving Grant Update function becomes equal to "Zero_Grant" or all processes 
are deactivated and TEBS is larger than zero, the transmission of a Scheduling Information shall be triggered. 

11.8.1.6.3 HARQ delivery failure for triggered Scheduling Information 

If the HARQ process fails to deliver a MAC-e PDU containing a triggered Scheduling Information to the RLS 
containing the serving cell: 

if the Scheduling Information was transmitted without any higher layer data multiplexed in the same MAC-e 
PDU: 

no further action is required (rely on periodic triggering). 

else (Scheduling Information was transmitted together with higher layer data multiplexed in the same MAC-e 
PDU): 

the transmission of a new Scheduling Information shall be triggered. 

11.8.1.7 MAC-es/e Reset 

If a reset of the MAC-es/e entity is requested by upper layers, the UE shall at the activation time indicated by higher 
layers: 

flush all HARQ processes. 

- set CURRENT_TSN to for all the logical channels mapped to E-DCH. 

NOTE: In this case, the HARQ entity will not notify the Scheduling Information Reporting function if a flushed 
MAC-e PDU contained a triggered Scheduling Information (rely on periodic triggering). 

1 1 .8.2 Node B operation 
11.8.2.1 HARQ Operation 

11.8.2.1.1 HARQ entity 

There is one HARQ entity per UE in each Node-B in its E-DCH active set. The HARQ entity routes the payload and the 
associated RSN value to the appropriate HARQ process based on the transmission timing. Based on the outcome of the 
decoding, the HARQ entity transmits an ACK or a NACK in return. 

11.8.2.1.2 HARQ process 

The HARQ process uses the RSN and the transmission timing (CFN, sub-frame) to establish the transmission number. 
Based on this it identifies the transmission redundancy version and attempts to decode the transmission. The outcome of 
the decoding is reported to the HARQ entity, so that it may be fed back to the UE. 
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11.8.2.2 De-multiplexing 

There is one de-multiplexing entity per UE in the Node B. The SRNC configures the Node B with the mapping between 
the active DDI values and the corresponding MAC-d flow and PDU size. Also, it provides it with the mapping between 
MAC-d flow IDs and the corresponding lub bearer. 

The de-multiplexing entity uses the MAC-e header information (DDI, N) to determine the size of each MAC-es PDU 
and based on this it segments the MAC-e payload into MAC-es PDUs. These are then routed onto the lub bearer 
indicated by the DDI value. 

With each MAC-es PDU, the Node B will send to the SRNC: 

the associated DDI and N values; 

the CFN and sub-frame numberwhen the payload including the MAC-es PDU was decoded correctly; 

the total number of transmissions that were needed for the MAC-e PDU to be decoded correctly. 

11.8.2.3 Scheduler 

There is one E-DCH Node B scheduler per Node B. The Node B scheduler is responsible for the following functions: 

Allocating uplink resources to UEs for which it acts as the serving Node B; 

Monitoring other-cell interference and accordingly sending relative grants to UEs for which it does not act as the 
serving Node B; 

Reporting to the SRNC on the lack of processing resources; 

1 1 .8.2.4 E-DCH Provided Bit Rate measurement 

The E-DCH Provided Bit Rate measurement is defined as follows: 

for each priority class the MAC-e function in the Node B measures the total number of MAC-d PDU bits whose 
transmission over the radio interface has been considered successful by MAC-e in Node-B during the last 
measurement period, divided by the duration of the measurement period; 

the number of MAC-d PDU bits from UEs in softer handover shall be considered after soft combining; 

the Node-B shall allocate the bit rate received over an RLS equally divided among all cells in the RLS regardless 
of whether the RLS contains the E-DCH serving cell or not; 

the values reported shall be raw samples; 

the measurement period shall be 100 ms. 

11.8.3 RNC operation 
1 1 .8.3.1 Re-ordering entity 

The re-ordering entity is part of the MAC-es sublayer in the SRNC. There is one re-ordering entity per UE. Each re- 
ordering entity will support one re-ordering process per logical channel. The DDI value is used to determine the logical 
channel for which each MAC-es PDU is meant. Based on this information, the MAC-es PDUs are routed to the proper 
re-ordering process. The re-ordering process may use the explicit TSN indication as well as the timing information 
provided by the Node B in order to eliminate duplicates and deliver the packets in order to RLC. The details of the re- 
ordering mechanism are left up to the implementation. 
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Annex A (normative): 

HS-DSCH Transport Block Size Table for FDD 

The following table provides the mapping between kf (as per the definition in subclause 9.2.3.1) and the HS-DSCH 
Transport Block Size (L(/Cf)): 



Index 



[ 


TB Size 


Index 


TB Size 


Index 


TB Size 


1 


137 


86 


1380 


171 


6324 


2 


149 


87 


1405 


172 


6438 


3 


161 


88 


1430 


173 


6554 


4 


173 


89 


1456 


174 


6673 


5 


185 


90 


1483 


175 


6793 


6 


197 


91 


1509 


176 


6916 


7 


209 


92 


1537 


177 


7041 


8 


221 


93 


1564 


178 


7168 


9 


233 


94 


1593 


179 


7298 


10 


245 


95 


1621 


180 


7430 


11 


257 


96 


1651 


181 


7564 


12 


269 


97 


1681 


182 


7700 


13 


281 


98 


1711 


183 


7840 


14 


293 


99 


1742 


184 


7981 


15 


305 


100 


1773 


185 


8125 


16 


317 


101 


1805 


186 


8272 


17 


329 


102 


1838 


187 


8422 


18 


341 


103 


1871 


188 


8574 


19 


353 


104 


1905 


189 


8729 


20 


365 


105 


1939 


190 


8886 


21 


377 


106 


1974 


191 


9047 


22 


389 


107 


2010 


192 


9210 


23 


401 


108 


2046 


193 


9377 


24 


413 


109 


2083 


194 


9546 


25 


425 


110 


2121 


195 


9719 


26 


437 


111 


2159 


196 


9894 


27 


449 


112 


2198 


197 


10073 


28 


461 


113 


2238 


198 


10255 


29 


473 


114 


2279 


199 


10440 


30 


485 


115 


2320 


200 


10629 


31 


497 


116 


2362 


201 


10821 


32 


509 


117 


2404 


202 


11017 


33 


521 


118 


2448 


203 


11216 


34 


533 


119 


2492 


204 


11418 


35 


545 


120 


2537 


205 


11625 


36 


557 


121 


2583 


206 


11835 


37 


569 


122 


2630 


207 


12048 


38 


581 


123 


2677 


208 


12266 


39 


593 


124 


2726 


209 


12488 


40 


605 


125 


2775 


210 


12713 


41 


616 


126 


2825 


211 


12943 


42 


627 


127 


2876 


212 


13177 


43 


639 


128 


2928 


213 


13415 


44 


650 


129 


2981 


214 


13657 


45 


662 


130 


3035 


215 


13904 
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46 


674 


131 


3090 


216 


14155 


47 


686 


132 


3145 


217 


14411 


48 


699 


133 


3202 


218 


14671 


49 


711 


134 


3260 


219 


14936 


50 


724 


135 


3319 


220 


15206 


51 


737 


136 


3379 


221 


15481 


52 


751 


137 


3440 


222 


15761 


53 


764 


138 


3502 


223 


16045 


54 


778 


139 


3565 


224 


16335 


55 


792 


140 


3630 


225 


16630 


56 


806 


141 


3695 


226 


16931 


57 


821 


142 


3762 


227 


17237 


58 


836 


143 


3830 


228 


17548 


59 


851 


144 


3899 


229 


17865 


60 


866 


145 


3970 


230 


18188 


61 


882 


146 


4042 


231 


18517 


62 


898 


147 


4115 


232 


18851 


63 


914 


148 


4189 


233 


19192 


64 


931 


149 


4265 


234 


19538 


65 


947 


150 


4342 


235 


19891 


66 


964 


151 


4420 


236 


20251 


67 


982 


152 


4500 


237 


20617 


68 


1000 


153 


4581 


238 


20989 


69 


1018 


154 


4664 


239 


21368 


70 


1036 


155 


4748 


240 


21754 


71 


1055 


156 


4834 


241 


22147 


72 


1074 


157 


4921 


242 


22548 


73 


1093 


158 


5010 


243 


22955 


74 


1113 


159 


5101 


244 


23370 


75 


1133 


160 


5193 


245 


23792 


76 


1154 


161 


5287 


246 


24222 


77 


1175 


162 


5382 


247 


24659 


78 


1196 


163 


5480 


248 


25105 


79 


1217 


164 


5579 


249 


25558 


80 


1239 


165 


5680 


250 


26020 


81 


1262 


166 


5782 


251 


26490 


82 


1285 


167 


5887 


252 


26969 


83 


1308 


168 


5993 


253 


27456 


84 


1331 


169 


6101 


254 


27952 


85 


1356 


170 


6211 
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Annex B (normative): 

E-DCH Transport Block Size Tables for FDD 

The mapping between the chosen E-TFCI and the corresponding E-DCH transport block size is given in the following 
tables: 

B.1 2ms TTI E-DCH Transport Block Size Table 



E-TFCI 


TB Size 


E-TFCI 


TB Size 


E-TFCI 


TB Size 


E-TFCI 


TB Size 


E-TFCI 


TB Size 




(bits) 




(bits) 




(bits) 




(bits) 




(bits) 





18 


30 


342 


60 


1015 


90 


3008 


120 


8913 


1 


120 


31 


355 


61 


1053 


91 


3119 


121 


9241 


2 


124 


32 


368 


62 


1091 


92 


3234 


122 


9582 


3 


129 


33 


382 


63 


1132 


93 


3353 


123 


9935 


4 


133 


34 


396 


64 


1173 


94 


3477 


124 


10302 


5 


138 


35 


410 


65 


1217 


95 


3605 


125 


10681 


6 


143 


36 


426 


66 


1262 


96 


3738 


126 


11075 


7 


149 


37 


441 


67 


1308 


97 


3876 


127 


11484 


8 


154 


38 


458 


68 


1356 


98 


4019 






9 


160 


39 


474 


69 


1406 


99 


4167 






10 


166 


40 


492 


70 


1458 


100 


4321 






11 


172 


41 


510 


71 


1512 


101 


4480 






12 


178 


42 


529 


72 


1568 


102 


4645 






13 


185 


43 


548 


73 


1626 


103 


4816 






14 


192 


44 


569 


74 


1685 


104 


4994 






15 


199 


45 


590 


75 


1748 


105 


5178 






16 


206 


46 


611 


76 


1812 


106 


5369 






17 


214 


47 


634 


77 


1879 


107 


5567 






18 


222 


48 


657 


78 


1948 


108 


5772 






19 


230 


49 


682 


79 


2020 


109 


5985 






20 


238 


50 


707 


80 


2094 


110 


6206 






21 


247 


51 


733 


81 


2172 


111 


6435 






22 


256 


52 


760 


82 


2252 


112 


6672 






23 


266 


53 


788 


83 


2335 


113 


6918 






24 


275 


54 


817 


84 


2421 


114 


7173 






25 


286 


55 


847 


85 


2510 


115 


7437 






26 


296 


56 


878 


86 


2603 


116 


7711 






27 


307 


57 


911 


87 


2699 


117 


7996 






28 


318 


58 


944 


88 


2798 


118 


8290 






29 


330 


59 


979 


89 


2901 


119 


8596 







B.2 2ms TTI E-DCH Transport Block Size Table 1 



E-TFCI 


TB Size 
(bits) 


E-TFCI 


TB Size 
(bits) 


E-TFCI 


TB Size 
(bits) 





18 


43 


2724 


86 


7252 


1 


186 


44 


2742 


87 


7288 


2 


204 


45 


3042 


88 


7428 


3 


354 


46 


3060 


89 


7464 
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4 


372 


47 


3078 


90 


7764 


5 


522 


48 


3298 


91 


7800 


6 


540 


49 


3316 


92 


7908 


7 


674 


50 


3334 


93 


7944 


8 


690 


51 


3378 


94 


8100 


9 


708 


52 


3396 


95 


8136 


10 


726 


53 


3414 


96 


8436 


11 


858 


54 


3732 


97 


8472 


12 


876 


55 


3750 


98 


8564 


13 


1026 


56 


3972 


99 


8600 


14 


1044 


57 


3990 


100 


8772 


15 


1062 


58 


4068 


101 


8808 


16 


1194 


59 


4086 


102 


9108 


17 


1212 


60 


4404 


103 


9144 


18 


1330 


61 


4422 


104 


9220 


19 


1348 


62 


4628 


105 


9256 


20 


1362 


63 


4646 


106 


9444 


21 


1380 


64 


4740 


107 


9480 


22 


1398 


65 


4758 


108 


9780 


23 


1530 


66 


5076 


109 


9816 


24 


1548 


67 


5094 


110 


9876 


25 


1698 


68 


5284 


111 


9912 


26 


1716 


69 


5302 


112 


10116 


27 


1734 


70 


5412 


113 


10152 


28 


1866 


71 


5430 


114 


10452 


29 


1884 


72 


5748 


115 


10488 


30 


1986 


73 


5766 


116 


10532 


31 


2004 


74 


5940 


117 


10568 


32 


2022 


75 


5958 


118 


10788 


33 


2034 


76 


6084 


119 


10824 


34 


2052 


77 


6102 


120 


11124 


35 


2070 


78 


6420 


121 


11178 


36 


2370 


79 


6438 


122 


11188 


37 


2388 


80 


6596 


123 


11242 


38 


2406 


81 


6614 


124 


11460 


39 


2642 


82 


6756 


125 


11478 


40 


2660 


83 


6774 






41 


2678 


84 


7092 






42 


2706 


85 


7110 







B.3 1 0ms TTI E-DCH Transport Block Size Table 



E-TFCI 


TB Size 


E-TFCI 


TB Size 


E-TFCI 


TB Size 


E- 


TB Size 


E- 


TB Size 




(bits) 




(bits) 




(bits) 


TFCI 


(bits) 


TFCI 


(bits) 





18 


30 


389 


60 


1316 


90 


4452 


120 


15051 


1 


120 


31 


405 


61 


1371 


91 


4636 


121 


15675 


2 


124 


32 


422 


62 


1428 


92 


4828 


122 


16325 


3 


130 


33 


440 


63 


1487 


93 


5029 


123 


17001 


4 


135 


34 


458 


64 


1549 


94 


5237 


124 


17706 


5 


141 


35 


477 


65 


1613 


95 


5454 


125 


18440 


6 


147 


36 


497 


66 


1680 


96 


5680 


126 


19204 


7 


153 


37 


517 


67 


1749 


97 


5915 


127 


20000 


8 


159 


38 


539 


68 


1822 


98 


6161 






9 


166 


39 


561 


69 


1897 


99 


6416 
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10 


172 


40 


584 


70 


1976 


100 


6682 




11 


180 


41 


608 


71 


2058 


101 


6959 




12 


187 


42 


634 


72 


2143 


102 


7247 




13 


195 


43 


660 


73 


2232 


103 


7547 




14 


203 


44 


687 


74 


2325 


104 


7860 




15 


211 


45 


716 


75 


2421 


105 


8186 




16 


220 


46 


745 


76 


2521 


106 


8525 




17 


229 


47 


776 


77 


2626 


107 


8878 




18 


239 


48 


809 


78 


2735 


108 


9246 




19 


249 


49 


842 


79 


2848 


109 


9629 




20 


259 


50 


877 


80 


2966 


110 


10028 




21 


270 


51 


913 


81 


3089 


111 


10444 




22 


281 


52 


951 


82 


3217 


112 


10877 




23 


293 


53 


991 


83 


3350 


113 


11328 




24 


305 


54 


1032 


84 


3489 


114 


11797 




25 


317 


55 


1074 


85 


3634 


115 


12286 




26 


331 


56 


1119 


86 


3784 


116 


12795 




27 


344 


57 


1165 


87 


3941 


117 


13325 




28 


359 


58 


1214 


88 


4105 


118 


13877 




29 


374 


59 


1264 


89 


4275 


119 


14453 





B.4 1 0ms TTI E-DCH Transport Block Size Table 1 



E-TFCI 


TB Size 
(bits) 


E-TFCI 


TB Size 
(bits) 


E-TFCI 


TB Size 
(bits) 





18 


41 


5076 


82 


11850 


1 


186 


42 


5094 


83 


12132 


2 


204 


43 


5412 


84 


12186 


3 


354 


44 


5430 


85 


12468 


4 


372 


45 


5748 


86 


12522 


5 


522 


46 


5766 


87 


12804 


6 


540 


47 


6084 


88 


12858 


7 


690 


48 


6102 


89 


13140 


8 


708 


49 


6420 


90 


13194 


9 


858 


50 


6438 


91 


13476 


10 


876 


51 


6756 


92 


13530 


11 


1026 


52 


6774 


93 


13812 


12 


1044 


53 


7092 


94 


13866 


13 


1194 


54 


7110 


95 


14148 


14 


1212 


55 


7428 


96 


14202 


15 


1362 


56 


7464 


97 


14484 


16 


1380 


57 


7764 


98 


14556 


17 


1530 


58 


7800 


99 


14820 


18 


1548 


59 


8100 


100 


14892 


19 


1698 


60 


8136 


101 


15156 


20 


1716 


61 


8436 


102 


15228 


21 


1866 


62 


8472 


103 


15492 


22 


1884 


63 
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Annex C (informative): 
Pseudo-Code for E-TFC Selection 

The pseudo-code below describes one possible implementation of the E-TFC Selection as described in subclause 
11.8.1.4: 

1> determine whether to take the scheduled and non-scheduled grants into account in the upcoming transmission. 

1> if scheduled and/or non-scheduled data can be transmited: 

2> select a MAC-d flow that allows highest-priority data to be transmitted (when more than one MAC-d flow 
allows data of the same highest priority to be transmitted, it is left to implementation to select which MAC-d 
flow to prefer); 

2> based on this MAC-d flow, identify the MAC-d flow(s) that can be sent according to their multiplexing list 
and ignore the one(s) that cannot. 

2> based on the HARQ profile of this MAC-d flow, identify the power offset to use; 

2> based on this power offset and the E-TFC restriction procedure, determine the maximum supported payload 
(i.e. maximum MAC-e PDU size or E-TFC) that can be sent by the UE during the upcoming transmission; 

2> set "Remaining Available Payload" to the maximum supported payload; 

2> if the upcoming transmission overlaps with a compressed mode gap on 10ms TTI, scale down the current 
serving grant (SG); 

2> set "Scheduled Grant Payload" to the highest payload that could be transmitted according to SG and selected 
power offset; 

2> for each MAC-d flow with a non-scheduled grant, set the "Remaining Non-scheduled Payload" to the value 
of the grant; 

2> set "Non scheduled Payload" to sum of MIN ("Remaining Non-scheduled Payload", non-scheduled available 
payload) for all non scheduled MAC-d flow(s); 

2> if Scheduling Information needs to be transmitted: 

3> if "Remaining Available Payload" > "Scheduled Grant Payload" + "Non-scheduled Payload" + size of the 
Scheduling Information: 

4> quantize the sum of the "Scheduled Grant Payload" + "Non-scheduled Payload"H- size of the 
Scheduling Information to the next smaller supported E-TFC; 

4> set the "Scheduled Grant Payload" to the quantized sum minus "Non-scheduled Payload" + size of the 
Scheduling Information. 

3> substract the size of the Scheduling Information from "Remaining Available Payload". 

2> else: 

3> if "Remaining Available Payload" > "Scheduled Grant Payload" + "Non-scheduled Payload": 

4> quantize the sum of the "Scheduled Grant Payload" + "Non-scheduled Payload" to the next smaller 
supported E-TFC; 

4> set the "Scheduled Grant Payload" to the quantized sum minus "Non-scheduled Payload". 

2> perform the following loop for each logical channel, in the order of their priorities: 

3> if this logical channel belongs to a MAC-d flow with a non-scheduled grant, then: 

4> consider the "Remaining Non-scheduled Payload" corresponding to the MAC-d flow on which this 
logical channel is mapped; 
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4> fill the MAC-e PDU with SDU(s) from this logical channel up to MIN("Remaining Non-scheduled 
Payload", Available Data for this logical channel, "Remaining Available Payload"); 

4> subtract the corresponding bits if any from "Remaining Available Payload" and "Remaining Non- 
scheduled Payload" taking into account the MAC-e headers. 

3> else: 

4> fill the MACe PDU with SDU(s) from this logical channel up to MIN("Scheduled Grant Payload", 
Available Data for this logical channel, "Remaining Available Payload"); 

4> subtract the corresponding bits if any from "Remaining Available Payload" and "Scheduled Grant 
Payload" taking into account the MAC-e headers. 

2> if Scheduling Information needs to be transmitted: 

3> add Scheduhng Information to the MAC-e PDU; 

3> determine the smallest E-TFC that can carry the resulting MAC-e PDU; 
2> else: 

3> determine the smallest E-TFC that can carry the resulting MAC-e PDU; 

3> if the padding allows a Scheduling Information to be sent, add it to the MAC-e PDU; 

2> set the maximum number of HARQ transmissions to the maximum among the maximum number of HARQ 
transmissions of the HARQ profiles of the MAC-d flows selected for transmissions. 

1> else if Scheduling Information needs to be transmitted: 

2> select the "control-only" HARQ profile; 

2> fill the MAC-e PDU with the scheduling information; 

2> select the smallest E-TFC. 
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